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The  importance  I  attach  to  program  management  in  the  acquisition 
of  major  weapon  systems  led  to  the  preparation  of  this  document;  Intro¬ 
duction  to  Military  Program  Management.  I  thought  we  needed  something 
which  would  capture  some  of  the  spirit  of  program  management,  illuminate 
the  objectives  of  our  policies  for  the  acquisition  of  major  systems,  and 
build  on  the  recent  experience  of  active  program  managers. 

I  believe  that  military  program  managers  will  benefit  from  a  thoughtful 
reading  of  this  volume.  At  the  same  time,  I  would  emphasize  that  it  is  not 
an  official  document.  It  does  not  purport  to  establish  DoD  policy,  and  in 
no  way  affects  responsibility  of  the  Services  for  the  definition  and  execution 


of  their  programs. 
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INTRODUCTION 


Purpose 

This  volume  is  intended  to  be  a  source  of  hints , 
something  of  lessons  learned,  and  pitfalls  seen  by  pro¬ 
gram  managers.  The  writers  approached  their  task  in  the 
spirit  of  being  helpful  and  mercifully  brief.  Whatever 
else  may  be  lacking,  the  manager  of  a  weapon  system  acqui¬ 
sition  program  cannot  complain  of  any  shortage  6f  reading 
material  with  liberal  references  to  even  longer  and  less 
interesting  works.  We  have  tried  to  focus  on  the  "art" 
of  program  management- -and  much  of  what  we  say  is  really 
a  reminder  about  things  already  known,  but  often  forgotten 
in  the  effort  to  cope  with  day-to-day  crises.  If  at  times 
we  sound  like  we  are  lecturing  about  the  obvious,  it  is 
because  we  are  convinced  that  what  can  be  communicated 
in  management  are  only  the  fundamentals — the  concepts 
that  will  prompt  the  program  manager  to  introspective 
thought  about  his  goals  and  his  techniques  of  management. 
This  volume  is  not  a  bible,  nor  a  handbook  on  program 
management.  Most  important,  it  is  not  directive  in  intent 
and,  hopefully,  not  directive  in  tone. 

The  question  might  now  be  raised,  since  it  will  not 
be  formally  addressed  later:  ’"What  is  management?"  A 
complete  answer  would  certainly  unbalance  this  book;  a 
short  answer  would  be  inadequate.  We  refer  you  instead 
to  the  799  pages  of  a  standard  treatise  on  the  subject, 
and  the  many  selected  references  following  each  chapter, 
in  Harold  Koontz  and  Cyril  O'Donnell,  Principles  of 
Management ,  McGraw-Hill,  1968. 

Having  now  mastered  the  principles  of  management — 
planning,  organizing,  staffing,  directing,  controlling, 
and  the  changing  environment  of  management — we  can  turn 
directly  to  military  program  management. 
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Organization 


Chapter  One  discusses  the  concept  of  military  program 
management,  the  role  of  the  program  manager,  and  his 
relationship  to  the  Service  organizations  and  to  the 
Office  of  the  Secretary  of  Defense  (OSD)  .  Chapter  Two 
discusses  program  objectives  and  trade-offs  within  the 
envelope  of  system  requirements.  That  chapter  also 
covers  system  planning,  risk  assessment,  and  risk  re¬ 
duction.  Chapter  Three  takes  up  program  interface  with 
contractors  and  some  of  the  more  significant  implications 
in  the  contracting  process.  The  next  three  chapters 
discuss  some  problems  affecting  system  objectives  of 
performance,  schedule,  and  cost.  The  order  of  mention 
is  not  intended  to  indicate  an  order  of  preference 

importance .  Indeed,  a  major  theme  of  this  guide  is 
that  performance ,  schedule ,  and  cost  are  three  inextri¬ 
cably  interwoven  parts  of  one  system  envelope .  In 
Chapter  Seven  we  discuss  some  ways  to  increase  the 
effectiveness  of  the  program  manager. 

Acknowledgements 

It  will  be  obvious  to  the  reader  that  we  are  indebted 
to  more  people  in  the  Department  of  Defense  and  in  industry 
than  we  can  acknowledge .  Without  their  guidance  and 
advice,  and  the  generous  contribution  of  their  time  and 
thoughts,  we  could  not  have  attempted  to  focus  on  the  real 
world  of  program  management.  Most  important,  of  course, 
were  the  contributions  of  present  and  past  military  pro¬ 
gram  managers  who,  in  fact,  best  know  the  real  world  of 
military  program  management.  The  program  managers  we 
interviewed  understood  that  none  would  be  quoted  directly. 
We  have  tried  to  capture  some  of  their  thoughts  and  words 
in  the  quotations  we  have  used— —many  of  which  are  para¬ 
phrases  and  composites  of  the  remarks  of  several  contri¬ 
butors  . 
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have  special  relevance  and  practical  guidance  for  military 

program  managers. 


CHAPTER  ONE 


THE  WORLD  OF  PROGRAM  MANAGEMENT 


The  Role  of  the  Program  Manager 

A  fundamental  Department  of  Defense  (DoD)  policy  is 
that  the  acquisition  of  major  weapon  systems  will  be 
directed  by  responsible  managers  under  the  concept  of 
program  management. 

The  concept  of  program  management  is  to  provide 
centralized  management  authority  over  all  of  the  tech¬ 
nical  and  business  aspects  of  a  program.  The  program 
manager's  role,  then,  is  to  tie  together,  to  manage, 
to  direct  the  development  and  production  of  a  system 
meeting  performance,  schedule,  and  cost  objectives 
which  are  defined  by  his  Service  and  approved  by  the 
Secretary  of  Defense  (SECDEF) .  The  essence  of  the  pro¬ 
gram  manager's  role  is  to  be  the  agent  of  the  Service 
in  the  management  of  the  system  acquisition  process,  to 
focus  the  authority  and  responsibility  of  the  Service 
for  running  the  program.  He  has  the  vantage  of  a  large 
perspective  of  the  program  and  the  interrelationships 
among  its  elements.  He  must  be  the  major  motive  force 
for  propelling  the  system  through  its  evolution. 

Recently ,  a  panel  of  military  program  managers  ex¬ 
amining  their  role  likened  it  to  that  of  the  general 
manager  of  a  small  company.  The  comparison  is  especially 
apt.  It  would  be  impossible  to  write  a  meaningful  posi¬ 
tion  description  for  that  job.  It  is  equally  impossible 
to  write  one  for  the  program  manager's  job.  What  the 
general  manager  does  is  whatever  is  needed  to  move  the 
a^a^rs  °f  the  business.  He  does  one  thing  at  one  time 
and  another  thing  at  another  time- -whatever  is  most  needed 
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at  the  moment  to  achieve  his  objectives .  A  general  mana¬ 
ger  is  not  a  "doer"  of  any  job — there  are  other  managers 
charged  with  the  doing.  But  the  general  manager  sees 
to  it  that  what  he  wants  is  done,  and  what  he  wants  is 
a  harmony  of  things  done  so  that  his  objectives  are 
achieved.  The  role  implies  reliance  on  others  to  do 
the  work;  but  it  also  implies  controlling  and  coordin¬ 
ating  the  work  so  that  no  one  aspect  dominates  others 
to  the  detriment  of  the  harmony  of  the  whole . 

This  touches  upon  what  is  likely  to  be  the  most 
important  function  of  the  program  manager:  getting 
people  to  communicate  with  each  other  to  achieve  a 
common  understanding  of  the  needs  of  the  program  and 
their  place  in  the  harmony  of  the  total  program  effort. 

Service  Responsibility 

It  is  some  oversimplification,  but  basically  correct, 
to  identify  three  players  and  their  respective  roles: 
the  Service,  the  program  manager,  and  OSD.  The  Service 
is  responsible  for  identifying  its  operational  needs  and 
defining  the  new  systems  required  to  meet  those  needs. 

It  is  also  reponsible  for  the  formulation  of  plans  for 
the  orderly  development  and  production  of  the  systems. 

The  program  manager  is  the  agent  of  the  Service  for  the 
formulation  and  execution  of  the  plan.  OSD  is  the  keeper 
of  the  Service  conscience — it  reviews  and  approves  the 
Service  plan  and  program.  But  the  center  of  systems 
acquisition  authority  and  responsibility  lies  in  the 
Service--more  specifically,  it  is  the  Service  Secretary. 

Approval  improperly  exercised  means  direction  in 
practice.  It  is  possible  to  withhold  approval  until 
the  one  approach  desired  by  the  approving  authority 
is  reluctantly  proposed  (or  stumbled  upon)  by  the  organi¬ 
zation  or  person  seeking  the  approval.  That  way  of 
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exercising  approval  is  directing— albeit  obliquely.  He 
who  exercises  "approval"  power  in  that  mode  is  seen  to 
have  assumed  the  role  of  directing,  while  perhaps  planning 
to  dodge  responsibility  if  things  go  wrong. 

Approval  means  something  else,  especially  in  the 
context  of  OSD's  role  in  military  program  management. 

It  denotes  a  dictionary  definition  of  the  word  approval: 

to  accept  as  satisfactory."  That  is  to  say,  it  is  the 
Service's  role  to  formulate  the  system  requirements  and 
plan  for  implementation.  It  is  OSD's  role  to  accept  the 
Service's  product  as  satisfactory— provided  it  is  consis¬ 
tent  with  major  policy  objectives.  It  is  also  OSD's  role 
to  evaluate  the  performance  of  the  Services  in  implementing 
the  approved  programs.  But  the  Service  has  the  final 
responsibility  for  getting  the  job  done. 

Judgment  and  Flexibility 

The  concept  of  program  management  evolved  because 
the  ordinary  way  of  doing  things  was  not  adequate  for 
the  task  of  managing  the  acquisition  of  complex  weapon 
systems.  Extraordinary  management — program  oriented 
management  was  essential  if  all  of  the  aspects  of  the 
program  were  to  be  handled  correctly  and  expeditiously. 

To  achieve  this  extraordinary  management,  there  is 
another  OSD  policy  which  complements  the  policy  requiring 
program  management:  military  program  managers  should  be 
free  to  exercise  judgment  and  flexibility.  Although  the 
program  manager  is  the  agent  of  the  Service,  he  should 
operate  in  an  environment  in  which  he  selects  and  tailors 
to  the  specific  needs  of  his  program  those  management 
systems  and  formal  techniques  that  will  help  his  program. 

He  should  operate  in  an  environment  conducive  to  the  ex¬ 
ercise  of  judgment.  There  is  no  pet  formula  a  program 
manager  can  adopt.  He  must  decide  for  himself  what 
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methods,  techniques,  and  systems  he  will  use.  If  the 
program  manager  is  responsible  for  planning,  directing, 
and  controlling  a  program,  he  must  have  the  authority 
to  get  the  job  done. 

Stated  another  way,  the  program  manager  is  encouraged 
to  adapt  standard  techniques  to  the  peculiar,  requirements 
of  his  program.  In  turn,  he  has  a  right  to  expect  that 
those  in  the  Services  who  are  going  to  approve  his  manage¬ 
ment  plans  and  techniques  will  exercise  their  power  of 
approval  properly.  That  is  to  say,  his  plans  and  techniques 
will  be  accepted  as  satisfactory  if  they  comply  with  basic 
policy  directives .  He  has  a  right  to  expect  that  his  plans 
will  not  be  judged  by  the  standard  of  meticulous  compliance 
with  innumerable  details  hidden  away  in  regulations,  direc¬ 
tives,  instructions,  handbooks,  manuals,  standards,  speci¬ 
fications  ,  or  similar  documents . 

What  the  program  manager  has  a  right  to  expect  and 
what  in  fact  he  will  be  offered  are  often  quite  different. 
Experienced  program  managers  would  remind  the  new  program- 
manager  that  often  one  must  struggle  to  obtain  the  manage¬ 
ment  flexibility  he  is  supposed  to  be  given.  Higher 
authorities,  and  especially  their  staff  organizations, 
tend  to  standardize  their  requirements  and  to  insist 
on  the  use  of  familiar  techniques  and  methods .  Their 
initial  disposition  is  to  avoid  changes  and  exceptions 
to  the  general  rule .  Requests  for  deviations  are  rarely 
conceded  without  being  pushed  and  sold. 

Functional  Support 

The  use  of  judgment  and  the  exercise  of  flexibility 
are  difficult  to  achieve  in  the  environment  of  military 
program  management.  The  most  significant  reason  for  this 
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is  that  the  operation  of  program  management  envisions  two 
organizational  elements.  In  some  few  cases  the  program 
staffed  with  all  or  most  of  the  capability  to 
perform  the  functional  activities.  In  these  cases  the 
program  office  is  largely  self-sufficient  and  does  not 
have  to  rely  on  much  support  from  functional  activities 
outside  of  the  line  authority  of  the  program  manager. 
Coordination  is  simplified,  but  the  problems  associated 
with  organizing  and  staffing  the  program  office  are 
magnified.  Usually,  however,  there  is  a  small,  cen¬ 
tralized  management  authority  consisting  of  the  program 
manager  and  his  program  office.  This  office  is  served 
by  functional  organizations  which  support  the  centralized 
authority  and  which  are  responsible  to  it  for  the  exe¬ 
cution  of  assigned  tasks.  This  environment,  where  the 
resources  for  doing  the  work  are  largely  outside  of 
the  line  authority  of  the  program  manager,  is  a  natural 
source  of  conflict. 

The  practical  fact  is  that  there  are  usually  several 
programs  competing  for  the  limited  resources  of  the  same 
functional  organizations.  Those  functional  elements  are 
also  supporting  the  normal  activities  of  their  parent 
organizations  the  day-to-day,  non-program  activities. 

When  personnel  are  not  available  to  support  all  of  the 
demands,  the  program  manager  finds  less  responsiveness 
than  he  desires  from  the  functional  elements.  His  situ¬ 
ation  is  made  even  more  difficult  because  the  functional 
elements  were  there  long  before  his  program  started  and 
they  plan  to  be  there  long  after  his  program  ends . 

Another  aspect  of  this  problem  is  the  tendency  of 
functional  specialists  to  see  their  discipline  as  the 
central  core  of  a  successful  program.  Their  commitment 
to  their  specialty  leads  them  to  try  to  dictate  to  the 
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program  what  will  or  must  be  done  as  distinguished  from 
advising  what  should  be  done.  Further,  there  is  no  lack 
of  regulations  with  which  they  can  bolster  their  claim. 
One  of  the  most  difficult  concepts  to  put  across  to 
functional  specialists  is  that  the  program  manager  is 
responsible  for  determining  what  will  be  done.  The 
functional  specialist  is  responsible  for  how  it  is  done 
the  how  being  his  area  of  expertise. 


There  is  a  natural  tendency  for  the  func¬ 
tional  managers  to  standardize  their  operations 
or  efforts,  to  perform  to  standards,  or  to  build 
a  standard  model.  A  project  manager  must,  through 
his  influence,  force  his  functional  areas  to  de¬ 
part  from  a  standard  and  build  something  that  fits 
in  with  the  other  parts  of  the  project.  Someone 
has  to  force  these  people  to  take  action  when 
these  actions  increase  a  functional  manager ' s 
risk  or  use  his  resources  at  a  greater  rate  than 
he  would  otherwise.  The  project  manager's  role 
is  to  balance  this  risk  over  all  portions  of  the 
project.  Therefore,  he  must  have  authority  to 
move  quickly  to  balance  his  risk.* 


Problems  with  functional  specialists  are  not  some¬ 


thing  new: 


The  expert,  in  fact,  simply  by  reason  of 
his  immersion  in  a  routine,  tends  to  lack  flexi¬ 
bility  of  mind  once  he  approaches  the  margins 
of  his  special  theme.  He  is  incapable  of  rapid 
adaptation  to  novel  situations.  He  unduly  dis¬ 
counts  experience  which  does  not  tally  with  his 
own.  He  is  hostile  to  views  which  are  not  set 
out  in  terms  he  has  been  accustomed  to  handle . 

No  man  is  so  adept  at  realizing  difficulties 
within  the  field  that  he  knows;  but,  also,  few 
are  so  incapable  of  meeting  situations  outside 
that  field.  Specialism  seems  to  breed  a  horror 


*George  A.  Steiner  and  William  G.  Ryan,  Industrial 
Project  Management,  the  Macmillan  Company,  1968,  p.  29. 
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of  unwonted  experiment,  a  weakness  in  achieving 
adaptability,  both  of  which  make  the  expert  of 
value  when  he  is  in  supreme  command 
of  a  situation.* 


The  environment  of  program  management  therefore  places 
an  extraordinary  premium  on  talent  for  leadership  as  dis¬ 
tinguished  from  command,  on  persuasion  as  distinguished 
from  direction.  The  environment  requires  an  emphasis  on 
informal  authority,  de  facto  authority,  or  influence  as 
distinct  from  power.  One  student  of  program  management 
has  described  this  authority  as  derived  in  part  from  the 
program  manager's  "persuasive  ability,  his  rapport  with 
extra-organizational  units,  and  his  reputation  in  resolving 
opposing  viewpoints  within  the  parent  unit  and  between  the 
external  organizations."** 


Persuasion  is  not  the  only  way  to  get  things  done. 

One  defense  program  manager  said  that  on  many  occasions  he 
overcame  the  opposition  of  functional  specialists  by 
"working  harder  than  they  did."  This  program  manager 
found  that  he  could  so  overwhelm  a  specialist  with  facts, 
figures,  and  analysis  that  it  became  too  much  of  an  effort 
for  the  specialist  to  refute  the  program  manager's  position. 


The  comments  of  this  program  manager  highlighted  a 
point  made  by  several  others  that  there  is  a  need  for  a 
strong  analytical  capability  in  the  program  office  to 


£  “ 

Harold  J.  Laski ,  "The  Limitations  of  the  Expert," 
r-5 f S  Mf9az:i-ne'  December  1930.  Quoted  in  Specialists 
and  Generalists,  a  selection  of  readings  by  the  Committee 
on  Government  Operations,  U.  S.  Senate,  90th  Congress, 

2d  Session,  1968,  p.  53. 


** 


David  I.  Cleland,  "Project  Management,"  Air-University 
Review ,  Vol.  XVI,  No.  2,  January-February ,  19 6  5~.  Reprinted 
in  a  book  of  readings  compiled  by  David  I.  Cleland  and 
William  R.  King,  Systems,  Organizations,  Analysis,  Management, 
McGraw-Hill  Book  Company  ,  19 6 9  .  "*  "  “  - 
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coordinate  a  program  whose  parts  were  organizationally 
and  geographically  widely  dispersed.  A  talent  for  analysis 
and  ability  to  work  with  people  were  the  key  criteria  in 
their  selection  of  program  office  personnel. 

Engagement  and  Disengagement 

In  common  with  the  way  a  general  manager  must  operate, 
the  program  manager  relies  on  others  to  do  the  work.  But 
he  cannot  escape  the  responsibility  for  the  result.  If 
he  is  responsible,  he  must  be  satisfied  that  what  is  done 
in  his  program  makes  sense  to  him  and  is  consistent  with 
his  plans.  If  he  cannot  be  persuaded  that  it  is  right  for 
his  program,  he  must  direct  it  to  be  done  the  way  he  wants. 

Much  has  been  written  about  the  role  of  industry  and 
the  relationship  that  should  obtain  between  the  defense 
program  manager  and  his  industry  counterpart.  Much  has 
been  said  about  "disengagement"— getting  out  of  industry's 
hair  and  letting  them  do  the  job  they  have  contracted  to 
do.  The  goal  is  laudable  and,  the  way  it  is  stated,  the 
idea  is  entirely  consistent  with  good  management  concepts. 
But  the  ultimate  responsibility  for  a  successful  program 
rests  squarely  on  the  Service  and  on  the  military  program 
manager  as  its  agent.  The  program  manager  cannot  dis¬ 
engage  in  any  literal  sense.  He  must  manage  contracted 
Work  in  just  the  same  sense  as  he  manages  all  the  other 
parts  of  his  program.  More  precisely,  in  this  case  he 
manages  contractor  management  of  his  program.  It  is  not 
a  question  of  whether  he  manages;  it  is  only  a  question 
of  how  he  manages — or  mismanages . 

Industry  project  managers  and  government  program 
managers  are  agreed  on  this  point: 

It  seems  clear  that  the  Government  program 
manager  must  exercise  rather  tight  control  until 
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such  time  as  he  is  assured  that  the  industrial 
project  manager  has  the  technical  and  managerial 
competence  to  perform  as  required.* 

ihe  obverse  is  equally  true,  however:  Once  the 
government  program  manager  has  obtained  the  assurance 
he  needs,  he  should  relax  his  control  and  concede  to 
his  contractors  a  measure  of  freedom  to  exercise  judg¬ 
ment  and  flexibility  similar  to  that  which  he  seeks 
for  himself. 

The  Soft  Sell 


Newly  appointed  program  managers  may  be  dismayed 
to  discover  that  there  is  less  than  complete  and  enthu¬ 
siastic  support  for  their  programs  within  their  Service 
and  OSD.  Every  weapon  system' competes  with  all  the  others 
for  limited  resources,  and  competition  is  especially  fierce 
m  periods  of  tight  budgets.  At  every  level  in  the  hier¬ 
archy,  commanders  and  staff  personnel  are  confronted  by 
demands  from  program  and  functional  managers  for  far  more 
money  than  is  available  or  can  reasonably  be  obtained. 
Budget  recommendations  and  decisions  must  be  made  that 
will  inevitably  favor  some  programs  over  others . 

The  program  manager  who'  has  done  his  homework  and 
has  kept  key  people  informed  about  his  system's  problems 
and  progress  will  improve  the  odds  that  funds  for  his 
program  will  not  be  reduced.  We  are  not  suggesting  that 
a  program  manager  affect  a  hard-sell  stance  or  that  he 
patrol  corridors  to  buttonhole  unwary  staff  people.  What 
we  are  suggesting  is  that  a  program  manager  should  be 
attuned  to  the  information  needs  and  biases  of  the  people 
who  influence  budget  decisions.  This  implies  a  kind  of 
low-key  salesmanship— of  the  soft-sell,  helpful  variety. 

Steiner  and  Ryan,  op .  cit . , 


p.  125. 
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One  of  the  project  manager's  greatest 
sources  of  authority  involves  the  manner  in 
which  he  builds  alliances  in  his  environment-- 
with  his  peers,  associates,  superiors,  subor¬ 
dinates,  and  other  interested  parties.  The 
building  of  alliances  supplements  his  legal 
authority;  it  is  the  process  through  which 
the  project  manager  can  translate  disagree¬ 
ment  and  conflict  into  authority  (or  influence 
power)  to  make  his  decisions  stand.  Sometimes 
the  power  and  control  of  the  project  manager 
represents  a  subtle  departure  from  his  legal 
authority . * 


The  program  manager  must  keep  in  touch  with  what  is 
going  on  above  him.  He  has  to  be  aware  of  what  is  expected 
of  him  by  higher  authority — both  in  his  Service  and  at  the 
OSD  level.  He  should  know  the  typical  questions  being 
asked  at  major  program  review  points,  and  he  should  be 
aware  that  these  requirements  for  information  by  higher 
authority  are  constantly  changing. 

Program  managers  speak  at  length  on  the  need  to 
instill  confidence  in  superiors.  This  confidence  is 
a  foundation  of  rapport  with  superiors  which,  in  turn, 
is  one  of  the  main  sources  of  the  program  manager's 
authority.  When  it  is  obvious  to  functional  managers 
supporting  the  program  that  the  program  manager  has 
this  rapport  with  his  superiors,  he  will  not  need  to 
rely  as  much  on  formal  authority.  One  of  the  ways 
this  confidence  can  be  instilled  is  by  demonstrating 
a  knowledge  of  the  program  in  the  widest  context. 

Knowledge  of  the  program  must  embrace  the  threat,  the 
direction  in  which  the  threat  is  evolving,  other  systems 
in  the  inventory  which  address  the  threat,  program 
schedules,  costs,  technology — in  short,  everything 
important  about  the  program. 

*David  I.  Cleland  and  William  R.  King,  Systems 
Analysis  and  Project  Management,  McGraw-Hill  Book 
Company,  1968,  p.  239. 
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The  Pentagon  Participants 

The  major  occasions  when  requirements,  plans,  and 
approval  come  together — the  interface  between  the  Service 
and  OSD  are  the  reviews  and  decisions  made  by  the  SECDEF 
at  three  critical  points  in  the  life  of  a  major  system: 


FUNCTIONAL  RESPONSIBILITIES  IN  THE  PROCESS  OF 

ACQUIRING  MAJOR  WEAPON  SYSTEMS 

CONCEPT¬ 

UAL 

PHASE 

PROGRAM 

DECISION 

VALIDA¬ 

TION 

PHASE 

RATIFI¬ 

CATION 

DECISION 

FULL-SCALE 

DEVELOP¬ 

MENT 

PRODUC¬ 

TION 

DECISION 

PRODUC¬ 

TION 

DEPLOY¬ 

MENT 

SECDEF 

X 

• 

X 

• 

X 

• 

X 

X 

SERVICE 

• 

• 

• 

• 

• 

•  Primary  Responsibility 

X  Monitoring  Responsibility 

The  SECDEF  makes  the  three  key  system  decisions  (the 
Program,  Ratification,  and  Production  Decisions)  by  choosing 
among  alternatives  posed  in  the  Development  Concept  Paper 
(DCP)  and  in  updated  versions  of  this  document.  He  also 
obtains  the  recommendations  of  the  Defense  Systems  Acqui¬ 
sition  Review  Council  (DSARC)  to  assist  him  in  making 
his  decision. 


The  DCP  is  the  primary  development  program  management 
document  in  OSD.  It  summarizes  the  essential  arguments 
which  the  SECDEF  must  consider  in  arriving  at  his  decision 
whether  to  continue  the  program  and,  if  continued,  in  what 
form  and  with  what  restraints.  It  is  a  document  prepared  by 
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the  Service  and  coordinated  among  all  interested  parties 
in  the  Services  and  OSD  by  the  Office  of  the  Director  of 
Defense  Research  and  Engineering  (ODDR&E) .  Program  managers 
are  usually  responsible  for  inputs  to  the  document,  and 
for  its  preparation  and  coordination  within  their  Service 
organizations . 

The  DCP  approved  by  the  SECDEF  will  identify  the 
limits  or  conditions  that  accompany  his  decision.  It 
will  also  identify  key  program  characteristics,  the 
expected  achievement  of  which  formed  the  basis  for  his 
decision.  These  are  the  thresholds,  or  operating  limits 
of  cost,  schedule,  and  performance  which  cannot  be  changed 
or  violated  without  SECDEF  approval.  These  thresholds 
require  the  Service  to  initiate  a  later  SECDEF  program 

{ 

review  if  the  limits  are  likely  to  be  exceeded.  Since 
the  program  manager  will  be  the  first  to  know  that  these 
limits  may  be  exceeded,  he  must  assume  a  special  burden 
to  be  sure  that  his  Service  authority  is  informed  of  all 
the  pertinent  facts  and  projected  results. 

The  DSARC ,  which  is  the  vehicle  for  OSD's  review 
of  the  program  being  recommended  by  the  Service ,  provides 
a  major  input  to  the  Secretary.  The  DSARC  is  composed 
of  the  Director  of  Defense  Research  and  Engineering, 
the  Assistant  Secretary  of  Defense  (Installations  and 
Logistics) ,  the  Assistant  Secretary  of  Defense  (Comp¬ 
troller)  ,  and  the  Assistant  Secretary  of  Defense 
(Systems  Analysis) .  The  Deputy  SECDEF  often  attends 
these  meetings . 

A  word  of  caution  is  appropriate.  The  life  cycle 
of  a  system  appears  in  the  preceding  chart  to  be  laid 
out  in  nice,  orderly  steps.  These  steps  may  seem  to 
be  a  one— two— three  progression  in  which  everything  is 
settled  before  one  proceeds  to  the  next  step.  If  weapon 
system  developments  were  so  orderly,  there  would  not 
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be  much  of  a  management  decision  involved  in  deciding 
to  proceed  further.  What  drives  the  process  is  that 
decisions  to  proceed,  or  to  stop,  or  to  change  direction, 
must  be  made  with  incomplete  facts.  Decisions  must  be 
made  in  situations  where  there  are  differences  of  opinion 
on  things  still  not  definitely  established.  Moreover, 
it  may  be  decided  that  some  steps  in  the  sequence  should 
be  omitted  entirely  or,  in  rare  cases,  that  two  steps 
should  be  pursued  concurrently  to  compress  the  time  to 
deployment.  What  is  important,  however,  is  that,  in 
making  such  a  decision,  SECDEF  requires  that  he  be  in¬ 
formed  of  the  potential  consequences.  He  also  requires 
a  choice  of  feasible  alternatives — alternatives  which 
^ave  been  studied,  shaken  down,  and  evaluated  from  every 
important  viewpoint.  The  program  manager's  role  in  this 
process  is  to  ensure  that  all  the  feasible  alternatives 
h^ve  been  uncovered  and  provided  to  the  Service  for 
presentation  to  SECDEF. 


CHAPTER  TWO 


PLANNING  AND  MANAGING  FOR  RISK  AND  UNCERTAINTY 


Program  Balance 

Program  balance  is  the  product  of  a  conscious  recog¬ 
nition  that  there  is  an  inescapable  interplay  among  the 
three  basic  program  elements  of  technical  performance, 
time,  and  cost.  It  is  a  product  of  an  awareness  that 
we  cannot  talk  about  what  we  want  without  also  talking 
about  when  we  want  it  and  how  much  we  can  afford  to  spend 
on  it.  Program  balance  also  involves  an  awareness  that 
the  balance  which  is  struck  at  the  beginning  of  the  program 
seldom  can  be  maintained  throughout  the  development.  New 
facts,  new  technology,  new  threats,  unexpected  costs — all 
upset  the  old  balance  and  require  a  new  balance  to  be 
struck . 

For  the  most  part,  techniques  to  establish  and  main¬ 
tain  program  balance  are  the  techniques  of  dealing  with 
risk — the  identification  and  evaluation  of  the  risks,  the 
selection  among  alternative  risks ,  and  the  plan  to  avoid 
or  reduce  risk.  By  risk,  we  mean  the  chance  of  being 
unable  to  obtain  what  we  want,  when  we  want  it,  for  the 
amount  we  want  to  spend  on  it.  Most  especially,  we  are 
talking  about  variations  in  the  total  risk  arising  out 
of  adjustments  in  our  objectives  for  performance,  time, 
and  cost.  We  are  talking  about  the  selection  of  the  best 
alternative  among  the  elements  of  risk--all  things 
considered. 

System  Requirements 

The  concept  that  requirements  can  be  written 
as  a  statement  of  need  that  is  independent  of  the 
means  to  satisfy  the  need  is  unsound.  It  leads 
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to  requirements  being  stated  either  in  terms  of 
rigid,  immutable  desires  or  in  terms  of  things, 
not  capabilities .  The  result  has  been  inflexible 
requirement  statements  that  make  no  provision  for 
changes . in  threat,  technology,  or  tactics;  inhibit 
initiative  and  imagination  in  development;  and 
often  result  in  costly  contract  changes  and  over¬ 
runs  .  * 


The  process  of  weapon  system  acquisition,  alluded  to 
frriefly  i-n  Chapter  One,  implies  something  very  different 
from  this  concept.  The  original  DCP  and  its  updating  at 
each  critical  decision  point  of  the  program  necessarily 
imply  an  unfolding  of  system  requirements  which  are 
changing  as  more  is  known  about  the  program.  In  each 
of  the  DCP  actions,  the  SECDEF  establishes  thresholds 
for  key  program  characteristics  of  performance,  schedule, 
and  cost.  He  requires  prompt  notice  if  any  of  these  limits 
will  not  be  met.  The  reason,  as  noted  earlier,  is  that 
these  key  characteristics — what,  when,  and  at  what  cost — 
individually  and  together  form  the  bases  for  each  deci¬ 
sion  to  proceed.  If  any  of  these  expected  values  does 
not  materialize  in  fact,  a  different  system  may  be  wanted 
or  perhaps  even  no  system  at  all.  Because  these  charac¬ 
teristics  are  at  the  very  heart  of  a  program  decision, 
they  cannot  be  changed  by  anyone  except  the  Secretary. 

The  point,  however,  is  not  that  they  cannot  be  changed. 

The  point  is  that  any  change  in  these  significant  require¬ 
ments  and  limits  involves  another  look  at  the  total  system 
to  answer  the  question:  Is  the  system  still  wanted?  Or 
is  there  another  and,  in  the  new  circumstances,  a  preferred 
alternative? 


Defense  Science  Board  Task  Force  on  R&D  Management, 
Final  Report  on  Systems  Acquisition,  ODDR&E ,  July  31,  1969, 

p.  4 . 
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The  consequences  of  failure  to  reexamine  a  program 
have  been  described  in  these  terms: 


We  have  come  to  a  time  when  meeting  certain 
targets  seems  to  have  become  more  important  than 
producing  a  satisfactory  system. . .  I  know  of  a 
number  of  cases  where  the  pressure  on  prediction 
has  been  so  great  that  the  Project  Manager  was 
forced  to  destroy  the  possibility  of  having  a 
good  system,  because  he  was  not  allowed  to  adjust 
what  he  was  doing  to  the  real  world;  otherwise 
he  would  have  been  sufficiently  far  off  predic¬ 
tion  in  one  or  another  dimension  that  the  project 
would  have  been  cancelled .  We  fell  between  two 
stools :  We  got  a  system  which  was  only  approxi¬ 

mately  what  we  wanted  and  the  system  failed  to 
meet  the  prediction.  Similarly,  we  also  have 
not  had  the  sense  to  cancel  something ,  which  met 
the  predictions,  but  was  no  damn  good.* 


In  a  practical  sense,  the  key  characteristics  approved 
by  the  SECDEF  and  spelled  out  in  the  DCP  become  program 
objectives  for  the  Service  and  the  program  manager.  There 
is  an  inclination  to  view  these  characteristics  as  sacro¬ 
sanct,  particulary  because  failure  to  achieve  them  may  be 
thought  to  threaten  the  program's  continuation.  That  view 
is  shortsighted.  Some  changes  in  key  characteristics 
may  be  so  obviously  advantageous  that  they  would  be  readily 
approved.  For  example,  a  modest  delay  in  schedule  and  a 
minor  added  cost  might  allow  an  exploitation  of  new  tech¬ 
nology,  possibly  resulting  in  a  significant  improvement 
in  operational  performance.  The  same  program  revisions 
might  also  permit  a  more  sequential  scheduling  of  risky 
development  steps.  This  could  substantially  improve  the 
likelihood  of  achieving  performance  goals.  A  much  more 
delicate  situation  arises  when  the  program  manager  decides 
that  one  or  more  of  these  characteristics  cannot  be  achieved 
at  all  or  achieved  only  if  another  is  sacrificed.  Program 

* 

Robert  A.  Frosch,  "The  Emerging  Shape  of  Policies 
for  the  Acquisition  of  Major  Systems,"  Naval  Engineers 
Journal ,  August  1969,  p.  22. 
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cancellation  or  an  extended  stretch-out  could  be  the  con¬ 
sequence  of  this  disclosure.  The  program  manager  may  be 
under  considerable  pressure  then  to  view  things  more 
optimistically.  Higher  authority,  in  some  cases  the 
Service  Secretary--but  not  the  program  manager--must 
decide  how  optimistically  a  given  situation  shall  be 
viewed . 

Trade-Offs 


The  program  manager  cannot  change  the  key  program 
characteristics  specified  in  the  DCP .  But  his  role  in 
the  acquisition  process  makes  him  the  one  person  who 
knows  best  what  beneficial  trade-offs  are  possible  dur¬ 
ing  any  stage  of  the  program.  As  a  consequence,  the 
program  manager  is  charged  with  ensuring  that  the  re¬ 
sponsible  Service  authority  receives  the  information 
required  to  evaluate  advantageous  trade-offs  as  early 
as  possible — and  as  often  as  necessary. 

Another  way  of  looking  at  program  balance  is  to  see 
it  as  trade-off  analyses  and  decisions  at  two  different 
levels  and  from  two  different  perspectives:  at  the 
OSD  level;  and  at  the  program  manager's  level,  as  an 
agent  of  the  Service . 

At  the  OSD  level,  the  overriding  objective  of  system 
acquisition  is  to  field  a  system  which  achieves  the  right 
balance  of  operational  effectiveness  and  total  program 
cost.  That  is  to  say,  what  is  sought  is  a  system  whose 
performance,  scheduled  availability,  and  total  program  cost 
represent  the  best  balance  of  requirements  and  resources. 
That  system  is  not  necessarily  the  lowest  cost  system 
satisfying  minimum  operational  requirements.  The  desired 
balance  reflects  consideration  of  the  value  of  any  im¬ 
proved  or  degraded  performance  or  schedule  characteristics — 
its  worth  in  terms  of  benefit  and  cost.  The  specified  key 
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program  characteristics  represent  a  decision  where  this 
balance  is  established  from  the  broad  perspective  of  an 
overview  of  DoD-wide  program  activities . 

Subject  to  the  constraints  of  the  specified  key  program 
characteristics,  there  is  a  whole  world  of  trade-off  deci¬ 
sions  to  be  made  on  other  desired  characteristics  specified 
by  the  user.  The  program  manager  and  the  user  must  contin¬ 
ually  balance  program  funds,  schedules,  and  the  desired 
characteristics  of  subsystem  performance.  These  trade-off 
decisions  are  a  continuing  process  throughout  the  program 
as  new  developments  and  unexpected  difficulties  force 
the  objectives  to  be  reconsidered  again  and  again.  The 
program  manager's  objective  is  to  field  a  system  meeting 
the  specified  and  the  desired  characteristics  at  the 
lowest  total  cost — and  certainly  at  no  more  than  the 
approved  program  cost. 

As  trade-offs  are  being  considered  during  the  program's 
evolution,  and  especially  when  unanticipated  technical 
problems  are  encountered  in  the  development  phase,  it 
may  become  evident  to  the  program  manager  that  some  of 
the  system  requirements  and  limitations  may  be  forcing 
trade-off  decisions  to  suboptimal  values.  It  may  be 
evident  that  a  better  balance  of  system  operational 
effectiveness  and  life  cycle  cost  would  be  obtained  by 
relaxing  one  or  more  of  the  constraints  on  key  program 
characteristics  instead  of  limiting  the  range  of  avail¬ 
able  trade-offs . 

That  is  to  say,  from  the  program  manager's  perspec¬ 
tive  of  one  program,  he  may  see  that  a  relaxation  of  one 
or  more  constraints — which  would  be  advantageous  to  his 
program — would  probably  also  be  acceptable  to  OSD  when 
viewed  from  the  broader  perspective  of  DoD-wide  interests. 

He  may  believe  that  the  best  program,  all  things  considered, 
should  be  different  from  that  approved  by  the  SECDEF.  In 
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these  circumstances,  the  program  manager  must  trigger  the 
actions  required  for  reexamination  of  program  objectives. 
To  do  otherwise  would  be  to  assume  incorrectly  that  sub- 
optimization  is  a  policy  goal. 


Planning 


The  objectives  and  importance  of  planning  in  defense 
management  are  much  the  same  as  in  industry. 


After  all  has  been  said  and  done  about 
systems  to  control  engineering  costs  and 
performance  after  the  decision  is  made  to 
embark  on  a  project,  it  is  the  project  plan 
prepared  before  starting  the  work  that  deter¬ 
mines  to  a  major  extent  the  outcome  of  a 
project  in  terms  of  time,  costs,  and  technical 
performance . 

Almost  universally,  there  has  been  a 
lack  of  realization  that,  once  a  project 
plan  is  accepted,  the  die  is  cast.  Further 
action  can  help  to  steer  the  course  of  the 
project  and  possibly  conduct  a  rescue  from 
disaster,  but  the  road  sign  to  the  disaster 
point  was  erected  when  the  project  plan  was 
written.  But  why  was  the  plan  faulty?  The 
answer  to  this  question  is  complex  and  not 
at  all  evident.  There  are  many  reasons  for 
faulty  project  plans.  Perhaps  the  outstand¬ 
ing  cause  is  a  lack  of  recognition  of  the 
importance  of  these  plans...  To  be  sound, 
a  project  plan  must  be  produced  through  a 
systematic,  detailed  analysis  that  includes 
breakdown  of  the  project  by  components, 
tasks,  work  packages,  events  (milestones), 
and  approaches,  rather  than  by  the  procedure 
known  as  SWAG  (Systematic  Wildly  Assumed 
Guess)  .* 

Planning  is  coming  to  grips  with  the  hard  details 
of  program  execution.  It  involves  the  examination 
and  reexamination  of  the  problems  which  are  anticipated 
and  the  alternative  ways  in  which  these  problems  might 
be  solved.  Coming  to  grips  with  these  details  and 


* 

Peter  C .  Sandretto ,  The  Economic  Management  of 
Research  and  Engineering,  John  Wiley  &  Sons,  Inc., 
1968,  pp.  91,  105. 


23 


evaluating  alternative  approaches  are  basic  steps  in  program 
formulation : 

The  next  consideration  in  developing  the 
project  plan  is  to  determine  the  approach  that 
should  be  taken  to  arrive  at  each  component 
and  the  tasks  involved  in  so  doing...  The 
procedure  described  above  may  appear  arduous 
but  is  very  necessary  for  producing  a  realis¬ 
tic  project  plan  that  will  result  in  the 
best  project  at  the  lowest  development  cost 
and  in  the  shortest  time.  The  engineer  or 
scientist  must  do  his  work  over  and  over, 
taking  into  account  every  possible  alterna¬ 
tive  solution.  Not  until  three  separate 
solutions  (complete  to  necessary  breakdown 
levels),  at  a  minimum  have  been  produced  and 
compared  can  it  be  said  that  there  exists  a 
project  plan  in  which  management  can  place 
its  trust.  Only  then  can  the  plan  be  relied 
on  not  to  place...  finances  in  jeopardy.* 


Planning  Essentials 

Department  of  Defense  management  policy  on  planning 
establishes  basic  objectives  which  are  expected  to  guide 
the  planning  process  and  channel  the  plans .  The  main 
policy  objective  of  defense  program  planning  is  to  main¬ 
tain  a  balance  between  dollar  commitments  and  program 
risks.  Its  objective  may  be  described  as  limiting  the 
amount  of  resources  committed  to  the  program  in  the 
event  that  the  results  of  development  efforts  require 
substantial  redirection — or  even  program  cancellation. 
The  technique  for  obtaining  this  balance  embraces  five 
interrelated  planning  activities  which  are  discussed 
in  turn: 


•  Assess  the  risk  implicit  in  alternative  subsys¬ 
tem  and  system  development  concepts.  Avoid 
alternatives  involving  low  probabilities  of 
success.  Reassess  risks  periodically  during 
the  development  program. 


Ibid. ,  p.  106 . 
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•  Reduce  concurrency  in  risky  situations  to  the 
maximum  extent  possible. 

•  Demonstrate  mastery  of  high  risk  elements 
before  proceeding  into  successive  program 
phases . 

•  Control  changes  and  be  sure  that  all  of  the 
schedule  and  cost  implications  of  a  proposed 
change  have  been  evaluated. 

•  Plan  for  unknowns. 


Assessing  Risk 

Although  risk  assessment  may  not  be  formally 
addressed  in  a  system  design,  it  cannot  be  ignored.  The 
selection  from  among  alternative  elements  that  make  up 
a  system  necessarily  involves  at  least  an  implicit  esti¬ 
mate  by  the  designer  of  the  likelihood  that  one  set  of 
elements  will  result  in  more  or  less  chance  of  success 
than  another. 


Inherently,  the  risk  of  failure  to 
meet  objectives  shadows  all  design  and  develop¬ 
ment  programs.  Yet,  because  it  is  a  negative 
aspect,  the  incidence  of  risk  is  quite  often 
overlooked  in  the  glare  of  optimism.  Or,  even 
where  it  is  not  ignored  completely,  it  may  be 
appraised  but  not  deeply  enough,  or  perhaps 
not  often  enough  to  serve  as  a  significant 
input  for  decision-making.* 


What  is  perhaps  new  in  defense  policy  is  emphasis 
on  identification  of  and  insistence  on  formal  analysis 
(explicit  estimates)  of  the  risks  associated  with  different 
alternatives .  The  concept  of  risk  assessment  is  made 
more  complicated  by  the  fact  that  the  lesser  risk  may 
not  be  the  optimum  choice.  Weapon  system  development 
extends  over  a  long  period — generally  not  less  than 


* 

James  R.  Polski,  "Managing  Risks  for  More  Effective 
Program  Control,"  Cleland  and  King,  op.  cit.,  p.  356. 
Reprinted  from  General  Electric  Company,  Missile  and 
Space  Division,  Aerospace  Management,  Vol.  1,  No.  1, 
Spring,  1966. 
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three  to  five  years.  Several  more  years  usually  elapse 
between  the  production  decision  and  deployment.  The  sys¬ 
tem  should  not  be  obsolete  when  fielded.  In  many  cases, 
it  must  push  against  the  boundaries  of  today's  technology 
if  it  is  not  to  be  obsolete  in  tomorrow's  environment; 
this  implies  taking  more  and  not  less  risk. 

Risk  assessment  in  this  context  is  a  decision¬ 
making  tool.  It  is  an  estimate  of  the  probabilities  of 
success  or  failure  associated  with  alternative  plans. 

It  is  also  a  measure  of  the  probability  of  meeting  speci¬ 
fied  performance,  schedule,  or  cost  goals  associated  with 
a  specific  plan,  and  the  sensitivity  of  this  probability 
to  changes  in  defined  parameters.  What,  for  example,  is 
the  range  of  probabilities  associated  with  costs,  given 
a  defined  set  of  technical  performance  and  schedule  require¬ 
ments?  What  are  the  schedule  and  cost  implications  of  less 
ambitious  performance  requirements — and  the  consequent 
elimination  of  one  or  more  high  risk  system  elements?  What 
we  are  really  talking  about  is  a  set  of  curves  displaying 
the  probability  of  certain  consequences  given  onie  and 
another  set  of  technical  performance,  schedule,  and  cost 
objectives . * 

As  a  decision-making  tool,  the  assessment  of 
risk  is,  then,  an  essential  factor  in  the  decision  process 
of  selecting  one  design  alternative  over  another.  It  is 
also  essential  in  deciding  whether  to  pursue  a  back-up 
development  program  to  improve  an  unacceptably  low  proba¬ 
bility  of  success  in  some  critical  subsystem  element. 
Further,  because  risky  designs  may  be  dictated  by  overstated 
requirements,  risk  assessment  also  plays  an  important  role 
in  the  determination  of  system  characteristics  and  in  the 

initial  program  decision. 

— - 

Some  techniques  for  risk  analysis  are  discussed 
in  Mr.  Polski ' s  article  cited  above  and  in  Richard  M. 
Anderson's,  "Handling  Risk  in  Defense  Contracting," 

Harvard  Business  Review,  July-August  1969,  pp.  90-98. 


26 


Risk  assessment  is  also  a  planning  device.  It 
embraces  a  plan  for  the  development  and  test  program  that 
will  resolve  uncertainty  in  identified  areas  of  major 
risk.  It  also  embraces  a  control  system  to  track  and 
measure  progress  toward  the  resolution  of  uncertainty — 
to  measure  the  reduction  of  risk  according  to  plan.  As 
with  any  other  planning  device,  risk  assessment  is  not 
a  one-shot  activity.  The  considerations  implicit  in 
the  initial  program  decision  must.be  reexamined  through¬ 
out  the  development  program.  Alternatives,  seemingly 
less  attractive  initially,  may  become  better  choices  as 
development  discloses  more  hard  facts.  Back-up  programs 
in  certain  areas  may  no  longer  be  the  best  investment 
of  scarce  resources  as  unanticipated  problems  are  encoun¬ 
tered  in  other  areas.  Program  characteristics  may  have 
to  be  reconsidered  as  new  data  show  that  the  overall  risk 
inherent  in  an  approved  program  was  underestimated. 

Reducing  Concurrency 

Conceptually,  concurrency  and  risk  reduction 
are  closely  related.  By  concurrency,  we  mean  overlapping 
program  phases,  such  as  undertaking  full-scale  development 
before  the  conceptual  phase  has  been  completed,  or  under¬ 
taking  production  before  development  is  completed.  Con¬ 
currency,  in  this  formal  sense  of  overlapping  major  program 
phases,  is  risky  business.  While  it  may  reduce  the  time 
span  from  concept  to  deployment,  it  involves  a  commitment 
to  incurring  substantial  costs  which  may  be  wasteful  in 
the  event  of  program  cancellation  or  redirection.  As  a 
matter  of  policy,  this  kind  of  concurrency  is  to  be 
avoided  and  will  be  approved  by  SECDEF  only  in  rare 
instances . 


There  is  another  kind  of  activity  that  is  some¬ 
times  called  concurrency.  It  embraces  those  steps  in  a 
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development  process  which  permit  an  orderly  transition  from 
one  phase  to  the  next.  For  example,  long  lead  time  materials 
may  have  to  be  ordered  in  advance  if  there  is  not  going  to 
be  an  unbearable  delay  in  the  transition  from  development 
to  production.  In  situations  like  these,  program  planning 
is  aimed  at  steering  a  course  between  delay  and  waste.  Risk 
assessment  is  a  means  of  estimating  the  amount  of  potential 
waste,  and  the  probability  that  the  waste  will  occur.  It 
would  be  best  to  view  this  kind  of  concurrency  as  something 
to  be  avoided  in  proportion  to  the  degree  of  risk  involved. 
The  question  then  is:  How  much  risk  is  there,  and  should 
or  must  that  risk  be  chanced? 

It  is  difficult  sometimes  to  distinguish  con¬ 
currency  in  the  formal  sense  from  normal  program  progres¬ 
sion.  What  looks  like  concurrency  may  be  an  integral  part 
of  both  a  previous  phase  and  a  successive  phase.  Is  a 
preproduction  model  for  test  the  beginning  of  production 
or  the  end  of  development?  Is  the  fabrication  of  the  pre- 
production  model  on  hard  tooling  an  essential  part  of  the 
development  testing?  If  it  is,  some  production  tooling 
will  have  to  be  ordered  and  made  before  development  is 
completed.  The  distinction  is  more  than  just  one  of  degree. 
Concurrency  in  the  formal  sense  implies  a  full-scale  ini¬ 
tiation  of  work  in  a  successive  phase  when  it  is  evident 
that  the  necessary  work  in  the  previous  phase  has  not 
been  completed.  That  is  not  permitted.  Concurrency  in 
the  loose  sense  is  a  product  of  orderly,  careful  planning. 
That  is  not  only  permitted,  it  is  essential. 

Reducing  Risk 


Each  program  must  be  treated  as  an  individual 
case,  but  there  are  two  general  rules  that  can  be  applied 
to  all.  First,  the  development  program  schedule  can  be 
examined  to  see  if  any  costly  work  which  might  be  signifi¬ 
cantly  affected  by  other  work  can  be  rescheduled  to  a 
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later  start  without  slipping  the  program  completion  date. 
Second,  the  impact  on  the  risk  of  wasted  work  of  slipping 
the  total  program  schedule  can  be  examined.  It  is  possible 
that  slippage  of  the  scheduled  date  for  operational  capa¬ 
bility  will  more  than  pay  for  itself  by  reducing  the  risk 
of  costly  rework  caused  by  concurrency.  This  is  especially 
likely  in  the  scheduling  of  initial  production  activities . 
Production  costs  are  usually  many  times  greater  than  develop¬ 
ment  costs  and  involve  commitments  for  a  wide  variety  of 
long  lead  time  items.  Changes  in  the  later  stages  of  devel¬ 
opment  are  likely  to  have  a  substantial  impact  on  production 
commitments .  Delaying  commitments  for  production  until 
successful  development  has  been  fully  demonstrated  is  likely 
to  have  a  large  payoff  in  total  program  cost. 

Other  ways  of  reducing  risk  also  require  tailoring 
to  specific  programs,  but  we  can  identify  approaches  that 
should  be  examined: 

•  Practical  trade-offs  between  operating 
requirements  and  engineering  design. 

•  Avoidance  of  high  risk  alternatives . 

•  Hardware  and  system  proofing  to  demonstrate 
that  risk  has  been  reduced  to  a  reasonable 
level . 

•  Back-up  programs  for  high  risk  elements 
of  the  system. 

•  Concentration  of  effort  early  in  high 
risk  areas . 

•  Program  scheduling  so  that  uncertainties 
are  resolved  before  putting  resources 
into  easy  parts  of  the  system  or  into 
the  full  program. 

Miles toning 

Milestones  are  events  whose  successful  accomplish¬ 
ment  signifies  completion  of  some  key,  meaningful,  and 
measurable  aspects  of  development  activities .  In  terms 
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of  risk  assessment,  they  represent  the  accomplishment  of 
some  aspect  of  the  program  by  proving  that  a  significant 
objective — an  event  with  an  identified  possibility  of 
failure — has  been  attained.  The  remaining  program  risk 
is  reduced.  In  some  other  context,  milestones  may  repre¬ 
sent  the  start  of  something  and,  because  they  are  usually 
associated  with  estimated  dates,  they  may  provide  some 
measure  of  adherence  to  schedules .  In  the  context  of 
the  essentials  of  program  planning,  however,  they  represent 
the  accomplishment  of  work;  schedule  is  secondary  to  the 
fact  that  progress  has  been  proved  objectively. 

Objectivity  is  an  essential  quality  of  milestones. 
Milestones  are  not  elastic  events  which  can  be  stretched  by 
emotional  rhetoric  or  tailored  by  fancy  to  fit  the  situation. 
They  are  events  which  have  been  programmed  in  advance.  They 
are  events  whose  successful  accomplishment  will  be  measurably 
hard  and  demonstrable  evidence  of  progress  toward  the  program 
goals.  Milestone  planning  necessarily  implies,  therefore, 
that  a  test  and  evaluation  program  is  tailored  to  the 
milestone  demonstrations.  If  milestones  are  not  to  become 
elastic  events,  test  routines  and  standards  must  be  spelled 
out  in  advance.  For  example,  first  flight  of  a  new  airplane 
is  .not  a  meaningful  event  without  defining  the  weight, 
speed,  altitude,  and  other  aspects  that  describe  the  accom¬ 
plishment  of  an  established,  definite,  measurable  objective. 

Key  milestones  play  an  important  part  in  DSARC 
reviews  and  SECDEF  decisions  to  proceed  into  successive 
program  phases.  They  answer  the  question:  Has  enough 
meaningful  progress  been  made  to  justify  increasing  the 
government's  financial  commitment?  The  decision  to  proceed 
can  be  based  either  on  wishful  thinking  or  on  demonstrable 
accomplishment.  It  is  not  a  recent  concept  of  management 
to  discount  wishful  thinking  and  to  insist  on  demonstrated 
achievement: 
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When  luck  is  even,  daring  is  rendered 
more  reliable  by  intelligence  and  the  sense  of 
superiority  it  gives;  intelligence  trusts  less 
to  hope,  the  strength  of  men  who  have  no  other 
resource,  than  to  judgment  based  on  facts,  from 
which  is  derived  sounder  foresight.* 

The  use  of  milestones  in  planning  and  control¬ 
ling  major  weapon  system  acquisitions  is  not  new.  Mile¬ 
stones — events  of  signif icance--occur  in  every  program 
and  are  used  by  decision  makers  at  various  levels .  A 
program  manager  will  use  a  large  number  of  schedule 
milestones  to  manage  his  program. 

Key  milestones--events  of  special  significance — 
are  of  interest  to  higher  levels  of  decision  makers  because 
they  are  selected  and  used  in  a  new  way.  They  are  used 
to  provide  progressive  assessment  of  the  reduction  of 
risk,  and  to  see  that  commitments  are  based  on  actual 
accomplishments ,  not  planned  accomplishments .  In  this 
manner,  decisions  which  commit  funds  or  reduce  available 
program  options  will  be  based  on  events,  and  not  on 
calendar  dates.  Time  is  made  a  variable  and,  when  appro¬ 
priate,  contract  provisions  will  be  written  to  provide 
alternatives  to  the  government  in  the  event  milestones 
are  not  met. 

Key  milestones — risk  assessment  milestones-- 
have  two  basic  purposes: 

•  In  planning  a  program — to  structure  the 
program  so  that  progressive  commitments 
are  made  only  when  justified  by  the 
remaining  level  of  program  risk. 


* 

From  Thucydides  (471-400  B.C.),  The  Peloponnesian 
Wars,  quoted  in  Specialists  and  Generalists,  op.  cit. , 
p .  3 . 
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•  In  managing  a  program — to  assure  that 
the  premises  on  which  program  commit¬ 
ments  were  originally  planned  have 
been  validated,  or  proven,  before 
additional  commitments  are  made. 


These  purposes  can  be  illustrated  in  a  simple 


way : 


Changes 


Change  control  is  based  on  two  related 

precepts : 


Let  a  good  thing  alone . 

What  looks  like  a  pussy  cat  may  turn 
into  a  tiger . 
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The  first  precept  stems  from  an  awareness  of  the 
real  world  of  development: 


Anyone  who  has  ever  done  a  development, 
or  a  design  (as  opposed  to  setting  up  a  manage¬ 
ment  system  for  doing  so)  is  well  aware  of  the 
fact  that  the  real  world  proceeds  by  a  kind  of 
feed-back  iterative  process  that  looks  more 
like  a  helix  than  like  a  line.  That  is  to  say; 
you  do  A,  then  B,  then  C,  then  you  look  at  C 
and  go  back  and  change  part  of  A  again,  and 
that  causes  you  to  fiddle  with  B  and  perhaps 
bring  in  a  B  prime  that  you  bounce  against  C, 
and  then  go  back  to  A  and  then. jump  to  D, 
so  that  there  has  to  be  continual  adjustment, 
going  back  and  forth  so  that  the  system  is 
adjusted  to  itself  and  to  its  end  objectives 
as  it  changes  and  as  the  design  or  development 
proceeds . * 


Changes  which  require  adjusting  parts  of  the 
system  whose  development  has  been  completed — and  especially 
any  fiddling  with  elements  of  large  risk  that  have  been 
successfully  surmounted  and  proved  by  tests — disturb  the 
whole  structure.  A  minor  change  looking  toward  a  modest 
improvement  may  have  an  impact  on  all  kinds  of  work  com¬ 
pleted,  in-process,  and  anticipated.  The  magnitude  of 
these  effects  is  hard  to  estimate,  but  must  be  considered. 

The  second  precept  stems  from  the  first.  Because 
the  magnitude  and  range  of  effects  are  hard  to  estimate, 
an  innocent-looking  change  may  play  havoc  with  cost  and 
schedule  objectives.  Major  redesign  may  be  required,  new 
elements  of  risk  are  introduced,  and  risks  previously  re¬ 
duced  or  eliminated  may  be  restored.  The  change  could  wreck 
the  program. 

Change  control  implies  these  rules: 

•  Aft  initial  predisposition  against  changes. 

If  in  doubt,  don't  make  the  change. 

* 

Robert  A.  Frosch,  op.  cit.,  p.  21. 
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•  A  detailed  analysis  of  the  direct  and 
the  likely  impact  of  a  change  on  all 
three  program  characteristics:  perform¬ 
ance,  schedule,  and  cost — especially  the 
last. 

•  A  continuing  predisposition  against 
change  after  the  analysis  is  completed. 
The  probability  is  that  things  will  turn 
out  much  worse  than  the  analysis  has 
predicted. 


These  rules  have  been  followed  by  a  number  of 
military  program  managers  who  said  that  their  change  policy 
was  to  have  no  changes  at  all — and  then  back  down  from 
there  only  when  there  was  overwhelming  and  convincing 
justification  for,  and  evaluation  of,  proposed  changes. 

Reckoning  With  Unknowns 

Planning  for  unknowns  is  the  last  of  the 
essentials  of  program  planning.  Unknowns  come  in  two 
varieties:  anticipated  unknowns  (or  known- unknowns )  and 

unanticipated  unknowns  (or  unknown-unknowns).  The  latter 
are  also  called  "unk-unks " . *  Planning  for  anticipated 
unknowns  is  the  basic  substance  of  risk  analysis  and 
plans  for  orderly  risk  reduction.  Probability  analysis 
as  a  tool  in  planning  necessarily  implies  recognition 
that  there  is  a  given  probability  (however  small)  of 
failing  to  achieve  some  objective  in  the  system  develop¬ 
ment.  This  recognition  should  in  turn  dictate  that  some 
thought  be  given  to  the  consequences  of  a  failure — a 

The  source  of  this  nomenclature  is  the  reports  of  the 
Aerospace  Technical  Council  of  the  Aerospace  Industries 
Association  (AIA) ,  Essential  Technical  Steps  and  Related 
Uncertainties  in  DoD  Weapon  Systems  Development.  There  are 
four  reports  in  this  series:  Phase  I,  May  1968;  Phase  II, 
September  1968;  Phase  III,  October  1969;  and  Phase  IV, 
December  1970.  All  four  contain  a  wealth  of  information 
and  insight  into  the  development  process  from  an  industry 
view . 
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failure  either  to  meet  a  performance  objective  or  a 
scheduled  target  for  some  system  element. 

The  possibility  of  failing  to  meet  a  performance 
objective  during  development  should  generate  a  "what  if?" 
plan.  The  alternative  may  be  program  cancellation.  It 
may  be  something  less ,  but  still  acceptable ,  in  the  way 
of  system  capability. 

The  possibility  of  failing  to  meet  a  schedule 
target  can  be  treated  by  recognizing  that  some  slippage, 
somewhere,  sometime  is  inevitable.  Consequently,  the 
total  system  schedule  must  allow  some  breathing  room — 
some  slack  time — to  accommodate  some  slippage.  The  pro¬ 
gram  must  not  be  so  tightly  scheduled  that  a  slippage 
has  an  unavoidable  and  devastating  effect  on  other  connected 
paths,  and  a  consequently  devastating  effect  on  program 
costs  or  deployment  schedules.  Building  some  slack  into 
a  program  is  hard  to  do,  .especially  when  external  pressures 
usually  demand  acceleration,  but  slack  is  absolutely 
essential . 


Planning  for  the  unk-unks  is  conceptually  dis¬ 
turbing.  How  can  one  plan  for  an  unknown  eventuality? 

It  is  especially  troublesome  because  the  AIA  study  of 
uncertainties  associated  with  specific  programs  identified 
many  problems  which  were  revealed  only  during  the  later 
phases  of  system  assembly  and  test: 

Problems  brought  to  light  in  this 
period  tend  to  show  the  need  for  significant 
changes  in  performance  specification  at  end 
item  and  system  levels,  usually  requiring 
revision  of  design,  with,  in  many  cases,  ad¬ 
verse  program  effects.* 


Ibid. ,  Phase  I  Report,  p.  8. 
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The  implications  for  system  program  plans  are 
obvious:  schedule  slippages  and  added,  unexpected  costs 

are  all  but  inevitable  in  these  later  phases- — time  and 
money  need  to  be  squirreled  away  in  each  of  the  major 
program  phases  for  the  rainy  day  that  is  certainly  coming. 
This  essential  slack  is  easiest  to  hide  when  it  is  built 
into  the  early  program  plans . 

A  further  implication  is  obvious:  subsystem 
hardware  tests  must  be  pushed  upstream  to  resolve  as 
much  uncertainty  as  possible  in  subsystem  elements  before 
the  program  is  besieged  with  system  problems.  A  good 
risk  analysis  and  risk  reduction  program  plan  already 
embrace  this  need. 


CHAPTER  THREE 


INDUSTRY  INTERFACE 


Importance 

The  term  "industry  interface"  is  not  merely  an  elegant 
expression  for  contracting,  although  it  includes  contrac¬ 
ting.  It  is  something  more.  It  suggests  some  feeling  for 
the  relationships  between  government  and  defense  industry — 
something  of  the  setting  in  which  the  system  acquisition 
process  takes  place.  It  also  implies  an  understanding  of 
some  of  the  things  which  influence  and  motivate  industry. 
The  interface  with  industry  has  peculiar  relevance  for 
military  program  managers.  By  far  the  larger  part  of 
total  program  acquisition  funds  will  be  spent  through  in¬ 
dustry  sources .  Program  planning  and  control  activities 
will  be  largely  dependent  on  industry  inputs.  Some  pro¬ 
gram  managers  have  had  very  little  direct  contact  with 
industry.  Given  the  reliance  on  industry's  efforts, 
much  of  a  program  manager's  time  and  attention  will  have 
to  be  devoted  to  problems  in  an  environment  which  may 
be  new  to  him. 

As  one  program  manager  notes : 


You  are  deep  in  contractor  problems  from 
the  beginning .  If  you  are  going  to  do  your  job 
right,  you  have  to  know  your  major  contractors-- 
their  history,  organization,  people,  and  the  way 
they  do  business.  To  understand  a  contractor, 
you  have  to  know  something  about  the  industry 
he  is  a  part  of--its  growth  or  decline,  and 
its  problems.  And  to  understand  an  industry, 
you  have  to  know  something  about  what  motivates 
business  in  general.  Industry  goes  to  great 
lengths  to  learn  everything  it  can  about  its 
cus tomer--the  government.  A  program  manager 
should  do  no  less  in  learning  about  his  major 
suppliers . 
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The  kind  of  information  needed  embraces  such  things 
as  areas  of  market  interest,  the  number  of  suppliers  and 
trends  toward  concentration,  interest  in  seeking  primarily 
commercial  or  government  work,  backlog  of  commercial  and 
government  work,  relationships  with  parent  organizations, 
recent  management  changes  and  reasons  for  the  changes , 
and  recent  organizational  changes.  Trade  journals  are 
a  useful  source  for  this  information.  The  procurement 
office  can  furnish  additional  information.  The  contract 
administration  people  in  the  field  who  have  cognizance 
of  the  contractor's  plant  can  provide  a  lot  of  insight 
into  recent  developments  and  trends  that  are  part  of  the 
intelligence  needed  to  understand  a  contractor. 

An  Unusual  Market  Place 

The  weapon  system  market  place  is  not  the  same  thing 
as  the  traditional  market  implicit  in  a  private  enterprise 
system.  The  traditional  market  place  is  one  teeming  with 
buyers  and  sellers,  each  striving  to  make  the  best  bargain 
he  can.  Supply  and  demand  determine  prices.  Sellers  vie 
with  one  another  to  attract  buyers  with  new  wares,  and 
buyers  will  substitute  other  items  if  they  cannot  satisfy 
their  preferred  requirements  at  what  they  consider  a 
fair  price. 

The  weapon  system  market  place  is  not  the  traditional 
market  for  one  obvious  reason.  There  is  only  one  buyer — 
the  government .  There  may  be  many  users ,  foreign  and 
domestic,  but  there  is  only  one  buyer.  There  are  other 
differences  which  are  at  least  partly  attributable  to 
there  being  only  one  buyer.  There  are  not  many  sellers 
of  the  highly  sophisticated  equipments  which  make  up 
today's  weapon  systems.  There  may  be  only  one  seller, 
or  a  few  at  most,  for  a  specific  system.  These  sellers 
are  largely  a  dedicated  industry.  That  is,  they  exist 
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primarily  to  satisfy  one  buyer's  requirements  for  goods 
and  services  which  they  cannot  sell  elsewhere.  The 
sellers  need  the  buyer  and  will  compete  fiercely  for 
his  business;  but  the  buyer  also  needs  the  sellers.  If 
the  buyer  does  not  conserve  his  suppliers ,  he  may  find 
no  one  who  can  satisfy  a  present  or  future  requirement. 

In  an  important  sense,  there  is  a  reversal  of  roles 
compared  with  the  traditional  market.  There  the  sellers 
attract  buyers;  in  the  weapon  system  market  place,  the 
buyer  attracts  the  sellers . 

One  consequence  of  the  fact  that  there  is  only  one 
buyer  and  only  a  few  sellers  is  that  there  is  a  limited 
number  of  competitors  for  major  programs.  The  competition 
itself  is  also  different.  In  the  traditional  market,  a 
sale  lost  one  day  may  be  captured  the  next.  But  in  the 
weapon  system  market  place,  the  next  sale  may  be  years 
in  the  future.  The  competition  is  often  for  nothing  less 
than  survival  as  a  source  in  an  area  of  established 
capability . 

For  its  part,  industry  feels  it  must  employ 
the  competitive  tactics  called  for  by  the  environ¬ 
ment  of  the  defense  marketplace.  A  contractor  who 
does  a  thorough  and  realistic  job  of  analyzing  and 
pricing  the  technical  risks  inherent  in  his  pro¬ 
posed  approach  to  systems  development  knows  that 
he  is  likely  to  find  himself  the  loser  to  a  more 
optimistic  competitor.  In  brief,  in  the  environ¬ 
ment  of  a  buyer's  market,  optimism  seems  essential 
to  survival.  This  inevitably  is  a  more  compelling 
motivation  to  the  seller  than  risk  minimization 
through  objective  realism  in  his  proposals,  the 
probable  end  result  of  which  is  losing  business.* 


This  auction  of  optimism  can  be  controlled  only  by 
evident  skepticism  on  the  part  of  the  program  office 
toward  unsupported  assertions . 

£  ■ 

National  Security  Industrial  Association  (NSIA) , 
Defense  Acquisition  Study,  Washington,  D.  C.,  1970,  p.  4. 
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In  addition  to  limited  competition  at  the  beginning 
of  a  program,  there  is  almost  no  hope  of  obtaining  com¬ 
petition  or  changing  sources  once  a  source  is  selected 
and  the  program  is  under  way.  The  selected  source  very 
quickly  acquires  people  and  experience — and  the  government 
acquires  a  sunk  cost  (both  money  and  time)  in  the  people, 
the  experience,  tools,  and  equipment — that  effectively 
precludes  changing  sources .  One  observer  described  this 
situation  vividly: 

Buyer  and  seller  are  locked  together  in  a 
relationship  analogous  to  bilateral  monopoly  for 
the  life  of  the  program,  and  they  must  deal  with 
each  other  on  a  bargaining  basis.* 

This  locking  together  of  the  contractor  and  the  Service 
highlights  a  major  difference  between  the  traditional  and 
weapon  system  markets.  In  the  traditional  market,  the 
seller  invests  in  the  product  development  and  brings 
finished  goods  to  entice  buyers.  The  buyer  is  not  an 
investor.  In  the  weapon  system  market  place,  the  Service 
pays  for  the  product  development  of  weapon  systems  because 
of  the  cost  and  risks  involved--it  is  both  the  buyer  and 
the  investor.  The  implication  of  this  dual  role  is  that 
the  Service  thereby  purchases  the  right  to  exercise  more 
control  over  its  weapon  systems  contractors  than  is 
usually  attributable  to  buyers. 


Contractor  Motivation 


The  long-term  motivation  of  contractors  is  survival . 

In  the  long-term,  survival  requires  profit.  There  must  be 
the  prospect  of  future  earnings  to  obtain  loans .  There 
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Frederick  M.  Scherer,  The  Weapons  Acquisition  Process: 
Economic  Incentives ,  Harvard  University,  1964,  p.  2~.  This 
and  a  companion  study,  Merton  J.  Peck  and  Frederick  M. 
Scherer,  The  Weapons  Acquisition  Process:  An  Economic 
Analysis ,  Harvard  University,  1962,  are  essential  background 
material  in  a  study  of  the  acquisition  process. 
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must  be  earnings  to  pay  interest  on  present  indebtedness 
and  to  retire  loans.  There  must  be  additional  earnings 
sufficient  to  satisfy  the  stockholders,  satisfaction  which 
is  obtained  by  dividends  on  their  investments  and  a  com¬ 
petitive  appreciation  in  the  value  of  the  company's  stock. 
Stockholders  may  be  long-suffering  in  anticipation  of 
better  days  to  come,  but  sooner  or  later  they  expect  satis¬ 
faction,  or  they  go  elsewhere  with  their  money. 

If  a  company  must  be  profitable  to  survive,  it  must 
also  survive  if  it  is  going  to  be  profitable.  If  it  cannot 
obtain  business,  it  will  not  survive.  In  the  short-term, 
therefore,  the  emphasis  is  on  survival  and  growth.  Profi¬ 
tability  is  much  less  important  in  the  short-term.  In  the 
short-term,  the  company  is  focusing  on  entering  new  programs, 
ensuring  its  continued  role  in  established  programs,  and 
seeking  ways  to  expand  its  role  in  these  programs.  Customer 
satisfaction  on  established  programs  is  important,  since 
it  determines  both  the  continued  role  and  the  possibly  ex¬ 
panded  role  of  the  company  in  the  program.  In  the  short¬ 
term,  this  customer  satisfaction  is  more  important  than 
stockholder  satisfaction.  This  means  that  in  most  situa¬ 
tions  a  program  manager  cannot  let  himself  be  lulled  into 
thinking  that  profit  or  the  opportunity  to  earn  an  extra, 
incentive  profit  will  motivate  his  contractors  toward 
the  objectives  he  seeks.  His  contractors  are  more  likely 
to  respond  to  his  candid  appraisals  of  their  performance 
which  communicate  clearly  his  satisfaction  or  dissatisfac¬ 
tion  with  their  efforts .  This  implies  the  need  for  personal 
involvement  with  the  contractors'  management  people. 

Studies  of  12  weapon  system  acquisition  programs  in 
the  period  1945-1960  clearly  indicated  that  the  way  to 
satisfy  the  military  customer  was  to  emphasize  weapon 
system  performance.  Maximizing  technical  excellence  was 
more  important  than  minimizing  development  time,  and  both 
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were  much  more  important  than  minimizing  cost.* *  The 
contractor's  reputation  would  suffer  most  from  failure 
to  achieve  technical  goals;  consequently,  weapon  system 
programs  generally  achieved  the  technical  goals,  but 
there  were  substantial  variances  in  development  time 
and  even  larger  variances  in  meeting  cost  objectives.** 
This  emphasis  on  technical  goals  at  the  expense  primarily 
of  program  cost  served  both  the  short-term  and  long-term 
objectives  of  defense  contractors.  In  the  short-term, 
contractors  were  giving  the  customer  what  he  wanted  most. 
In  the  long-term,  they  were  enchancing  their  technical 
reputation  and  increasing  the  scope  and  the  depth  of  their 
technical  resources.  These  increased  technical  resources 
would,  in  turn,  improve  the  contractors'  capabilities  and 
enhance  their  chances  of  being  selected  for  other  weapon 
system  development  programs. 

The  importance  of  technical  excellence  to  both  the 
government  and  contractors  is  no  less  today  than  it  was 
earlier.  What  is  different  today  is  defense  management's 
insistence  that  technical  excellence  must  not  be  pursued 
without  also  pursuing  schedule  and  cost  objectives. 

This  attention  to  schedule  and  cost  objectives  puts 
pressures  on  technical  achievements  that  are  not  present 
when  technical  excellence  is  the  only  or  dominant  goal . 
Schedules  and  budgets  must  reflect  the  obvious  (but  often 
overlooked)  fact  that  although  technical  achievements  can 
be  scheduled  and  good  management  can  help  to  keep  them 
on  schedule,  they  are  not  achieved  on  demand  or  by  edict. 
The  pressures  which  cost  and  schedule  objectives  put  on 
technical  achievement  sometimes  result  in  efforts  to 
achieve  savings  at  the  expense  of  essential  technical 
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Peck  and  Scherer,  op.  cit.,  pp.  288-298. 
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steps.  The  program  manager  must  be  wary  of  suggestions 
that  certain  tests  can  be  eliminated  or  documentation 
delayed  in  the  name  of  savings.  This  attitude  of  wariness 
is  appropriate  whether  the  suggestions  come  from  contractors 
or  from  his  own  staff. 

Contracting 

Contracting  is  a  functional  expertise,  like  many 
other  functional  activities  which  contribute  to  success¬ 
ful  program  execution.  Yet,  it  is  something  special  for 
the  program  manager.  Most  of  the  program  output  will  be 
obtained  through  industry  sources,  and  contracting  is  the 
means  of  achieving  arrangements  with  these  sources .  If 
mistakes  are  made,  they  are  longer-lasting  and  less  amen¬ 
able  to  simple  correction  than  mistakes  in  other  functional 
areas.  Moreover,  the  art  of  contracting  is  particularly 
dependent--if  it  is  to  be  done  right — on  an  understanding 
of  the  program's  requirements.  Only  someone  intimately 
familiar  .with  present  and  future  program  plans  can 
communicate  this  understanding.  That  someone  should  be  the 
program  manager.  It  must  be  the  program  manager  if  he 
wants  the  right  results . 

The  objective  of  the  contracting  process  is  to  get 
the  best  source  working  for  the  program  under  the  best 
arrangement.  Every  program  manager  and  every  contracting 
officer  ought  to  agree  on  this  motherhood  statement.  More 
important,  they  ought  to  agree  on  what  logically  follows 
from  it — that  competition  is  a  tool  for  identifying  the 
best  source  and  that  the  contract  is  a  vehicle  for  defining 
the  best  arrangements. 

It  would  be  unrealistic,  however,  not  to  acknowledge 
that  there  is  a  predisposition  to  conflict  between  the 
technical  people  in  the  program  and  the  contracting  people. 
To  technical  people,  the  contracting  officer  is  often  viewed 
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as  a  policeman  waving  his  book  of  unintelligible  rules,  in¬ 
sisting  on  competition  for  its  own  sake,  unwilling  to  accept 
technical  judgments  on  the  sources  which  should  be  used, 
emphasizing  price  to  the  exclusion  of  any  other  considera¬ 
tion,  and  generally  making  more  work  and  slowing  things 
down.  To  contracting  people,  the  technical  man  is  often 
viewed  as  emphasizing  technical  quality  to  the  exclusion 
of  everything  else,  unwilling  to  consider  contractor  past 
performance,  always  behind  schedule  and  trying  to  make  it 
up  with  a  quick  contract  award,  disdainful  of  lead  time 
realities,  wedded  to  his  contractor,  unmindful  of  laws 
and  regulations,  and  generally  going  too  fast  and  taking 
too  many  shortcuts .  Both  have  experienced  one  or  many 
occasions  of  frustration  with  the  other,  when  their 
expressed  views  were  only  a  pale  reflection  of  their 
innermost  thoughts. 

Type  of  Contract 

There  are  essentially  two  basic  types  of  contracts: 
fixed  price  and  cost-reimbursement.  There  is  an  endless 
variety  of  pricing  arrangements  which  shade  toward  one  or 
the  other.  This  variety  makes  it  difficult  (and  perhaps 
a  little  silly)  to  talk  about  the  effect  of  one  or  another 
type  but  some  differences  are  61ear  at  the  extremes . 

The  characteristic  of  a  fixed-price  contract  is  that 
there  is  a  legal  commitment  to  deliver  something — hardware, 
a  report,  or  a  service--no  matter  what  the  actual  cost  of 
performance  may  be.  If  the  cost  of  performance  exceeds  the 
contract  price,  the  contractor  suffers  a  loss.  Theoret¬ 
ically  at  least,  the  loss  may  grow  larger  and  larger  as 
the  contractor  strives  to  deliver  what  he  has  contracted 
to  deliver.  If  the  contractor  fails  to  deliver,  he  will 
be  paid  nothing  for  the  effort  made.  Indeed,  in  its 
usual  form,  a  fixed-price  contract  gives  the  government 
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the  right  to  procure  from  another  source  and  to  collect 
from  the  unsuccessful  contractor  any  added  costs. 

The  characteristic  of  a  cost-reimbursement  contract 
is  that  the  contractor ' s  legal  commitment  is  to  work  at 
what  he  is  supposed  to  do,  but  only  if  the  government 
reimburses  him  for  the  costs  he  incurs  in  trying.  If  the 
government  stops  paying  for  the  work,  the  contractor  has 
no  further  obligation  and  there  is  no  liability  for  costs 
which  may  be  incurred  by  the  government  in  going  to 
another  source. 

The  differences  between  these  two  types  of  contracts 
are  very  marked.  Equally  marked  differences  are  evident 
i-n  their  impact  on  competition  and  on  the  pressures  they 
put  on  the  contractor  and  the  program.  A  feeling  for  the 
consequences  of  these  differences  is  important.  Three 
facts  must  be  kept  in  mind,  however.  First,  the  more 
extreme  form  of  fixed-price  contract  is  rarely  used  in 
the  larger  and  more  important  contracts  entered  into  in 
the  early  phases  of  the  weapon  system  acquisition  process. 
Second,  the  way  in  which  a  contract  is  administered — 
changes ,  for  example — can  shade  a  fixed— price  type  contract 
toward  a  cost-reimbursement  arrangement.  Third,  the  form 
of  the  contract  is  only  one  factor  in  any  given  situation — 
other  factors  (such  as  the  contractor's  current  work  load 
and  future  prospects)  may  be  far  more  important  in  their 
effect  on  the  contractor. 

•  A  dollar  amount  on  a  cost— reimbursement  contract 
is  not  a  price.  It  is  only  an  estimate.  The 
price  will  be  what  it  actually  costs  to  do  the 
work,  and  the  program  manager  must  manage  the 
contract  and  budget  with  that  fact  in  mind. 

•  If  the  contractor  will  be  reimbursed  for  his 
costs,  as  contrasted  with  what  he  estimates, 
there  is  a  tendency  to  beat  the  competition 
by  underestimating  cost  and  overestimating 
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what  can  be  done  for  those  dollars .  The 
estimates  quoted  by  contractors  are  not  a 
sound  basis  for  selecting  one  over  another 
in  a  competitive  situation.  If  the  con¬ 
tractor  will  be  held  to  a  fixed  price,  no 
matter  what  the  costs,  there  is  a  built-in 
restraint  on  puffery  and  the  prices  quoted 
have  some  validity  for  source  selection. 

•  If  the  contractor  will  be  reimbursed  what  it 
costs,  he  is  likely  to  accept  guidance,  direc¬ 
tion,  and  redirection  by  the  program  personnel. 
It  will  cost  him  nothing  to  be  cooperative, 
although  the  result  may  be  a  cost  overrun  on 
his  earlier  estimate.  If  a  contractor  will  be 
held  to  a  fixed-price,  he  will  resist  this 
direction.  He  will  seek  formal  change  notices 
to  adjust  his  price  for  the  new  work  being 
thrust  upon  him. 


Among  the  host  of  errors  that  can  be  made  in  contrac¬ 
ting,  the  one  with  the  greatest  potential  for  generating 
problems  is  selection  of  the  wrong  type  of  contract. 

Although  other  factors  may  cause  an  entirely  different 
response,  a  fixed-price  contract  motivates  a  contractor 
to  do  a  minimum  job,  to  do  the  least  work  that  must  be 
done,  to  choose  the  lowest  cost  solutions  to  problems  that 
may  arise.  A  fixed-price  contract  drives  a  contractor 
that  way  because  the  government  is  telling  him  that  he  will 
be  paid  some  fixed  sum  for  the  results  described  in  the 
contract.  This  may  be  exactly  what  the  government  wants 
to  tell  a  contractor  in  certain  circumstances.  But  if  the 
government  wants  and  expects  something  more,  the  contract 
should  reflect  that.  Perhaps  you  might  expect  the  contractor 
to  do  what  benefits  the  government  without  a  corresponding 
benefit  to  the  company.  But  it  is  unreasonable  to  assume 
that  the  contractor  should  do  anything  which  is  detrimental 
to  his  own  interests.  A  cost-reimbursement  contract  over¬ 
comes  this  problem  but  not  without  substituting  a  different 
problem.  If  the  government  will  pay  the  actual  costs  in¬ 
curred  by  the  contractor ,  what  is  the  incentive  to  keep 
costs  as  low  as  possible? 


46 


ibe  selection  of  the  right  type  of  contract  is  influ¬ 
enced  by  the  Service-contractor  roles  implicit  in  each  type 
The  program  office  looks  a  little  silly  if  it  complains 
that  the  contractor  is  uncooperative  with  respect  to  sug¬ 
gestions  for  technical  improvements  when  the  contract  is  a 
fixed-price  contract  with  all  sorts  of  provisions  fixing 
performance  responsibility  on  the  contractor.  The  coopera¬ 
tion  sought  by  technical  people  in  those  circumstances  is 
akin  to  a  friendly  assist  to  the  contractor  on  his  way  to 
the  poorhouse.  If  program  office  or  government  laboratory 
personnel  are  going  to  play  a  significant  role  in  deciding 
how  the  contractor  will  go  about  his  work,  and  the  contract 
does  not  reflect  that  fact,  there  undoubtedly  will  be 
conflicts . 

Competition 


The  main  advantage  to  the  government  of  competition 
is  the  advantage  of  motivating  a  contractor  to  not  inflate 
his  estimate  of  costs.  The  possibility  that  another  con¬ 
tractor  may  be  able  to  satisfy  the  government's  requirement 
at  a  lower  price  is  a  powerful  incentive  to  match  or  beat 
the  competition.  Another  significant  advantage  of  competi¬ 
tion  to  the  government  is  in  motivating  design  improvement-- 
to  beat  the  competition  with  a  better  product.  The  better 
product  may  cost  more:  what  really  beats  the  competition  is 
better  value  for  comparable  dollars.  Competition  encourages 
innovation  and  cost  control  by  contractors. 

Competition  and  type  of  contract  are  different  subjects 
but  they  are  related.  Competition  is  a  problem  in  the  envi¬ 
ronment  of  much  of  the  weapon  system  development  process . 

^  source  selection  is  made  early  in  the  development 
cycle,  the  type  of  contract  presents  an  enigma.  If  a  fixed- 
price  contract  is  used,  the  contractor  assumes  the  risk 
involved  in  proposing  firm  prices  for  something  not  yet 


47 


developed.  If  a  cost-reimbursement  contract  is  used,  con¬ 
tractors  are  likely  to  underestimate  costs  and  overestimate 
what  can  be  achieved  in  their  desire  to  obtain  the  contract 
award.  In  addition,  at  this  early  stage,  the  government 
is  unlikely  to  have  a  sound  basis  for  an  independent  evalu¬ 
ation  of  cost  estimates  for  either  type  of  contract. 

Competition  on  a  fixed-price  contract  basis  is  desir¬ 
able  when  the  program  office  knows  what  it  wants,  has  a 
design  which  it  can  describe,  can  write  explicit  specifi¬ 
cations,  and  the  work  can  be  done  largely  without  guidance 
from  the  program  office .  Some  parts  of  the  total  program 
will  meet  these  criteria.  For  these  parts  of  the  program, 
the  best  price  will  be  obtained  by  fixed-price  contracts, 
and  their  costs  can  be  budgeted  accurately.  But  when 
what  is  wanted  is  something  new  and  different,  when 
what  is  sought  is  really  development  rather  than  pro¬ 
duction,  fixed-price  contracting  and  price  competition 
are  too  simplistic.  The  contract  arrangements  appro¬ 
priate  for  any  given  situation  can  be  determined  only 
after  a  hard  look  at  what  is  wanted  and  what  is  known  about 
it — and  with  a  realistic  appraisal  of  the  risks  involved. 

Knowledge  and  the  risks  involved  in  a  development 
undertaking  are  not  static.  A  contract  form  inappropriate 
at  an  early  stage  may  become  appropriate  at  some  later 
stage.  Contract  arrangements  can  be,  and  should  be,  changed 
accordingly.  But  in  the  early  stages,  we  are  likely  to  know 
little;  consequently,  the  risks  are  likely  to  be  great. 

When  you  are  dealing  with  development, 
procurement  is  not  a  way  of  buying  something. 

It  is  a  way  of  making  arrangements  to  get 
something  done....  In  the  development  sit¬ 
uation  there  is  no  object  to  purchase,  there 
is  only  an  objective  to  purchase .  There 
is  no  defined  piece of  hardware  that  can  be 
priced  in  the  same  sense  as  we  price  a  manu¬ 
factured  object.  Nevertheless,  in  attempting 
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to  buy  development  we  behave  as  if  there 
really  was  such  an  object.  We  act  as  if 
the  airplane  that  we  had  put  a  name  to  and 
specifications  on,  has  in  fact  real  charac¬ 
teristics  and  a  defined  real  price. 

From  an  engineering  point  of  view  at  the 
point  in  time  at  which  we  purchase  development, 
there  is  no  such  object.  We  are  only  purchas¬ 
ing  somebody's  plans,  somebody's  objectives, 
somebody's  proposal  against  a  set  of  specifi¬ 
cations  that  we  think  are  what  we  want  to  buy . 
The  specifications  are  made  from  a  set  of 
requirements  that  we  think  are  what  we  want. 

If  we  actually  had  a  definable  object,  defin¬ 
able  in  the  sense  that  we  could  give  precise 
description  to  what  it  was,  and  know  that  when 
we  got  it,  it  would  work  correctly  and  be  what 
we  wanted,  then  there  would  be  no  sense  of 
entering  a  development  project  at  all;  we  could 
simply  go  out  and  buy  it. 

The  whole  point  of  a  development  process 
is  to  get  something  that  we  haven't  got,  some¬ 
thing  that  we  have  never  seen,  and  something 
which  we  don't  really  knoy?  can  be  produced.* 


One  way  out  of  this  dilemma  is  for  the  Service  to 
sponsor  competition  until  competing  designs  are  developed 
to  the.  point  where  fixed-price  contracts  can  be  entered 
into  in  a  competitive  environment  for  the  balance  of  the 
program.  This  approach  is  called  parallel  development. 
Two  or  more  contractors  are  sponsored  until  the  Service 
can  make  a  selection  among  competing  designs  and  prices 
in  a  competitive  environment.  Parallel  development  is 
carried  on  until  three  conditions  are  satisfied.  First, 
the  contractors  must  know  enough  about  their  designs 
to  assess  accurately  the  risk  they  would  be  embracing 
in  proposing  to  complete  the  program  on  a  fixed-price 
basis .  Second,  the  Service  must  know  enough  about  the 
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designs  to  select  the  best  alternative--price  and  all 
other  factors  considered.  Third,  the  Service  must  be 
able  to  assess  the  risk  being  assumed  by  the  contractors 
and  independently  determine  that  it  is  reasonable  for 
the  contractors  to  assume  that  degree  of  risk. 

Sponsoring  two  or  mbre  contractors  for  parallel 
development  is  going  to  cost  more  in  the  early  program 
stages.  The  cost  of  competing  on  that  basis  is  usually 
too  large  for  a  company  to  undertake  unless  the  govern¬ 
ment  sponsors  and  pays  for  it.  The  additional  expense 
may  be  recouped  by  obtaining  lower  prices  in  the  later 
program  phases  than  would  be  obtained  in  the  absence 
of  competition.  Another  benefit  is  the  added  assurance 
of  a  successful  program  because  of  the  reduced  risk 
implicit  in  parallel  efforts .  Competition  can  be 
sponsored  at  the  system  contractor  level,  among  major 
subsystem  elements,  or  at  both  levels.  Whether  it  is 
advantageous  to  sponsor  competition,  and  at  what  level 
of  system  work  breakdown  structure,  are  mostly  matters 
of  judgment.  The  decision — whether  the  benefits  are 
worth  the  added  cost  of  development — must  turn  on  the 
facts  in  the  specific  program: 

•  The  relative  costs  of  development  and  production. 

The  development  costs  to  the  point  of  a  sound 
basis  for  contractor  selection  must  be  compared 
to  the  costs  of  anticipated  production.  If  the 
development  costs  are  relatively  low,  competition 
in  development  looking  toward  competitive  pricing 
of  production  is  more  advantageous  than  it  would 
be  if  development  costs  are  relatively  large. 

•  The  pricing  environment. 

If  the  item  is  one  for  which  there  is  a  sub¬ 
stantial  pricing  history  and  there  is  confidence 
in  the  accuracy  of  cost  estimates,  competition 
is  not  needed  as  much  as  it  is  if  the  government 
would  be  dependent  on  contractor  cost  estimates 
for  production. 
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•  The  technical,  schedule,  and  cost  risks. 

If  the  risk  of  failure  is  relatively  large  and 
the  consequences  costly,  parallel  development 
is  advantageous  as  a  planned  reduction  of  risk . 


To  highlight  the  range  of  problems  associated  with 
competition  and  type  of  contract,  we  might  suppose  a 
situation  where  competition  can  be  obtained,  and  a  con¬ 
tract  can  be  written  holding  the  contractor  to  a  high 
level  of  required  performance  on  a  fixed-price  contract 
basis .  It  may  seem  that  the  program  manager  need  not 
concern  himself  with  questions  about  the  reasonableness 
of  these  arrangements.  After  all,  no  one  is  forcing 
contractors  to  commit  themselves .  They  could  refuse 
to  bid.  The  winning  bidder  should  be  assumed  to  know 
what  he  is  doing.  We  must  not  lose  sight  of  the  fact, 
however,  that  successful  completion  of  the  work  is  the 
main  objective — and  cost  or  price  is  only  one  aspect 
of  the  program.  A  contractor  may  yield  to  the  govern- 
m®nt  s  superior  bargaining  position  and  agree  to  a  high 
risk  development  effort  on  a  tight  fixed-price  basis 
because  it  may  be  "the  only  game  in  town".  If  the 
result  of  the  arrangement  were,  in  fact,  to  bankrupt 
the  company  before  it  had  completed  the  work,  the  pro¬ 
gram  manager  would  still  have  the  same  problem  he 
s^arted  with  the  problem  of  completing  the  development 
and  production  of  an  operational  system.  In  addition, 
he  would  have  acquired  another  problem — a  schedule  bind. 

Perhaps  the  most  important  single  point  is  that  system 
contracting  is  a  complicated  subject.  Every  situation  has 
its  own  unique  problems .  Experience  begets  a  feel  for  the 
nuances  which  make  the  difference  between  rote  application 
of  ^ules  and  sensitive  creativity.  A  program  manager  who 
has  directed  two  defense  programs  sees,  it  this  way: 
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One  thing  you  must  do  is  lock  your  technical 
people  together  with  your  lawyer  and  your  contract¬ 
ing  officer.  A  contract  is  a  legal  agreement.  The 
lawyer  and  the  contracts  man  find  the  weaknesses 
and  the  inconsistencies — they  are  trained  to  find 
the  soft  spots.  They  can  focus  business  judgment 
on  the  procurement.  But  if  they  are  going  to  be 
helpful  they  have  to  be  in  on  the  whole  deal  early 
and  stay  with  it.  Don't  look  on  them  as  paper- 
pushers.  They  should  be  reading  the  specifications 
and  requirements  right  along  with  the  technical 
people.  Their  function  is  to  tell  you  whether 
you  can  contract  on  the  basis  you  have  fashioned 
and  whether  you  can  enforce  it  if  you  are  pushed. 
Similarly,  the  technical  people  should  be  reading 
the  proposed  contract  right  along  with  the  lawyer. 
They  have  to  live  with  the  deal  every  day,  and  it 
had  better  make  sense  to  them,  too. 


In  a  real  sense,  it  all  goes  back  to  fundamentals. 

If  the  program  manager,  the  technical  people,  the  lawyer, 
and  the  contracting  officer  communicate  with  each  other, 
the  right  contracting  methods  can  be  found.  If  they  do 
not  communicate  the  facts  and  the  real  intent,  problems 
are  inevitable. 


Pick  a  Winner 

The  selection  of  the  major  system  prime  contractor  is 
the  single  most  momentous  decision  in  the  management  of  the 
program.  A  bad  choice  is  a  curse,  a  good  choice  is  a 
blessing,  and  a  mediocre  choice  means  more  work  for  the 
program  manager.  Every  part  of  the  program  activity  will 
be  touched  by  the  prime  contractor:  subcontract  management 
for  major  subsystems,  program  budget  forecasts,  schedule 
compliance — everything.  The  benefit  of  his  excellence  or 
the  debilitating  effect  of  his  incompetence  will  be  evident 
everywhere  and  every  day . 

This  being  the  most  important  single  decision  in  the 
program  operation,  it  may  seem  incongruous  that  the  selec¬ 
tion  is  taken  out  of  the  program  manager's  hands  to  be 
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made  at  a  considerably  higher  level,  perhaps  even  at  the 
level  of  the  SECDEF .  It  is  not  incongruous,  however,  if 
we  consider  the  public  interest  involved  in  decisions  of 
such  dollar  magnitude;  and,  whether  incongruous  or  not, 
it  is  the  general  policy.  The  program  manager  may  or  may 
not  play  a  formal  role  in  the  source  selection  process — 
that  will  depend  on  Service  policy.  But,  whether  or  not 
he  plays  a  role  in  the  source  selection  process,  and 
although  he  will  not  make  the  official  selection,  the 

manager  has  a  personal  stake  in  the  results .  He 
can  (and  should)  influence  selection  activities  to  protect 
his  stake.  A  major  opportunity  is  provided  in  supporting 
the  selection  process.  He  will  do  much — if  not  all— of 
the  original  staff  work  in  proposing  the  evaluation  cri¬ 
teria  and  developing  the  list  of  recommended  sources  to 
be  solicited. 


There  are  important  ways  in  which  the  final  results 
can  be  influenced  by  the  program  manager: 


•  The  sources  selected  for  conceptual  studies 
will  obtain  program  visibility  that  will  en¬ 
hance  their  position  in  later  phases  of  the 
program.  The  framework  for  effective  compe¬ 
tition  can  be  constructed  in  the  selection 
of  contractors  for  these  studies.  Good 
sources  can  be  encouraged  to  become  inter¬ 
ested  in  the  program  and  to  stay  interested. 
Persuasion  may  be  essential  if  the  program 
is  not  yet  well  established  and  there  is  a 
likelihood  that  it  may  be  cancelled  or 

s tretched-out . 

•  The  best  people  are  not  always  assigned  to 
source  selection  duties  by  the  functional 
elements.  The  program  manager  should  use 
his  personal  contacts  to  get  the  better 
people  assigned.  Command  support  should 
be  solicited,  if  necessary. 

•  Program  office  personnel  should  be  made 
available  to  participate  in  the  source 
selection  process  even  though  they  can 
hardly  be  spared  from  other  duties .  The 
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program  manager  will  want  to  nominate 
someone  from  the  program  office  as  chair¬ 
man  of  the  Source  Selection  Evaluation 
Board,  the  group  that  performs  the  detailed 
evaluation  of  proposals .  The  outcome  is 
too  important  to  be  left  to  others  who 
will  have  less  reason  to  care  about  the 
results . 

•  The  factors  which  will  be  used  in  proposal 
evaluation — and  the  relative  weighting  of 
these  factors — should  be  tailored  to  the 
requirements  of  the  individual  program. 

Items  important  to  the  management  of  the 
program  must  not  be  lost  in  a  welter  of 
technical  minutia.  Management  factors 
are  important  and  likely  to  be  slighted 
at  the  expense  of  the  program  manager's 
future  well  being.  He  must  see  that  the 
experience,  ability,  and  authority  of  the 
program  managers  which  the  industry  sources 
propose  to  assign  to  his  program  are  care¬ 
fully  examined.  This  factor  should  be  given 
significant  weight  in  the  evaluation  process . 

•  Good  system  design  is  another  factor  likely 
to  be  overlooked  in  the  evaluation  process . 
The  Evaluation  Board  forms  into  panels,  and 
specialists  will  examine  every  subsystem 
element.  The  program  manager  will  want  to 
ensure  that  the  Board  also  looks  at  the  total 
system. 


What  is  true  of  major  formal  source  selection  pro¬ 
cedures  is  true  also,  in  relative  terms,  for  the  smaller 
contracts  where  proposal  evaluation  and  source  selection 
are  performed  in  the  program  office  or  by  a  supporting 
functional  element.  Although  the  processes  are  much  less 
formal,  the  need  to  select  the  best  is  no  less  significant, 
and  the  use  of  appropriate  criteria  is  no  less  important 
to  the  program  manager.  The  magnitude  of  his  potential 
headache  is  not  necessarily  proportional  to  the  size  of  the 
contract.  Moreover,  a  rigorous  insistence  on  selection  of 
contract  sources  by  objective  standards — rather  than  by 
subjective  whim — will  have  a  salutary  effect  on  the  climate 
for  rational  thought  and  action  for  both  the  program  office 
and  its  contractors. 


CHAPTER  FOUR 


TECHNICAL  ACHIEVEMENT  PROBLEMS 


Putting  Technical  Achievement  in  Perspective 

Given  unlimited  time  and  money,  there  are  scarcely 
any  problems  of  technical  performance.  Almost  any  technical 
problem  which  does  not  involve  sorcery  can  be  wrestled  to 
the  ground  eventually  or  drowned  in  a  sea  of  cash.  If  this 
is  true ,  it  also  may  be  said  that  there  are  only  problems 
of  schedule  or  funds.  There  may  be,  however,  one  purely 
technical  problem.  That  one  is  where  the  system  fails  to 
satisfy  the  user's  requirements  and  is  something  the  user 
neither  needs  nor  wants.  This  situation  could  develop  from 
an  ambiguous  statement  of  requirements,  further  compounded 
by  inadequate  coordination  with  the  user  on  trade-off 
decisions.  Even  in  this  extreme  case,  however,  added 
time  and  additional  funds  could  solve  the  problem.  You 
could  even  start  all  over  again. 

It  is  clear  that  technical  performance  (the  product) 
cannot  be  isolated  completely  from  time  and  money  (the 
resources) .  Problems  of  technical  performance,  in  general, 
will  be  manifested  as  resource  problems.  The  technical 
problems  addressed  in  this  chapter  are  inextricably  bound 
up  with  resource  implications.  This  relationship  should 
not  be  obscured  by  the  fact  that  the  problems  are  addressed 
as  technical  ones. 

In  one  sense,  problems  of  technical  performance  are 
the  least  of  the  program  manager's  worries.  There  is 
general  agreement  among  experienced  program  managers  that 
time  is  their  greatest  strain,  even  when  the  original  plan 
was  acknowledged  to  be  reasonable .  Time  seems  to  evaporate 
mysteriously,  and  everything  takes  longer.  The  strain  of 
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time  is  closely  followed  by  dollars .  Performance  is  their 
least  troublesome  concern  because  the  developers — whether 
industry  sources  or  government  laboratories — concentrate 
on  achieving  performance.  But  in  striving  for  performance, 
they  tend  to  downgrade  the  importance  of  schedule  and  funds . 
The  program  manager  is  not  likely  to  add  much  of  anything 
to  the  program  if  he  pursues  the  same  objective  everyone 
else  is  chasing.  His  contribution  should  be  .to  focus  atten¬ 
tion  on  schedule  and  cost  to  maintain  a  balanced  program. 

Engineering  Optimism 

Optimism  is  not  a  trait  peculiar  to  scientists  and 
engineers.  The  problem  is  that  engineering  optimism  easily 
reaches  epidemic  proportions.  Nothing  is  impossible  for 
talented  designers  and  developers,  and  the  greater  the 
scientific  and  engineering  challenge  the  more  fun  it  is. 

This  optimism  is  an  essential  ingredient  of  human  progress . 

It  is  also  an  essential  attribute  if  technical  innovation 
is  to  be  made  in  new  weapon  developments.  On  the  other  hand, 
optimism  leads  to  an  overestimate  of  the  ease  of. doing 
something  and  a  corresponding  underestimate  of  the  time  and 
resources  it  will  take.  Management's  problem  is  to  keep 
the  spirit  alive  to  obtain  the  benefits  but,  at  the  same 
time,  avoid  the  detrimental  consequences  of  overoptimism. 
Engineering  optimism  is  great — it  is  even  essential--but 
someone  has  to  administer  the  antidote  if  there  is  going 
to  be  program  balance.  The  antidote  is  skepticism. 

Skepticism  is  the  second  requisite  of  engineering 
management.  Planning  is  the  first.  If  planning  is  carried 
through  in  the  detail  and  with  the  coordination  that  are 
essential,  it  will  disclose  what  has  to  be  done.  Skepticism 
will  probe  the  estimate  of  how  simple  it  will  be  to  do  it. 
The  searching  question  is:  Just  what  makes  you  think  the 
estimate  or  prediction  is  worth  a  tinker's  dam?  The  obscur¬ 
ing  smoke  of  optimism  has  to  be  dispelled  sufficiently  so 
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that  the  real  basis  of  the  estimate  can  be  exposed.  The 
estimate  may  be  soundly  based — but  it  may  have  emerged  from 
someone's  imagination.  Persistence  and  insistence  on  full 
disclosure  are  absolutely  vital.  Two  benefits  can  be 
expected  from  a  searching  inquiry:  one  is  a  lessening 
of  overreaching  technical  sophistication;  the  other  is 
a  better  program  plan. 

The  problems  associated  with  engineering  optimism  are 
especially  murky  in  programs  which  are  deemed  to  be  "well 
within  the  state-of-the-art."  These  programs  are.  repre¬ 
sented  to  be  simple  stuff,  hardly  worth  serious  technical 
contemplation;  off-the-shelf  items — requiring  only  that 
someone  put  the  pieces  together,  using  today's  technology. 

It  usually  doesn't  work  that  way.  Anyone  who  has  assembled 
a  set  of  stereo  hi-fi  systems — using  off-the-shelf  components 
and  then  spent  hours  (or  days)  tracking  down  the  sources  of 
the  hum  and  ear-shattering  acoustic  feedback  knows  better 
than  that.  In  the  Defense  Department,  some  of  the  most 
highly  publicized  cases  of  cost  growth  involved  programs 
that  originally  were  thought  to  require  simple  technology 
and  modest  engineering  skills.  Don't  believe  it  when  an 
engineer  says,  "It's  easy."  Make  sure  he  has  thought 
about  it.  More  important,  take  a  close  look  at  the  test 
program  which  will  demonstrate  that  it  has  been  achieved 
so  easily. 

Engineering  optimism  also  manifests  itself  in  a 
single-path  technical  approach.  It  is  economical  and 
certainly  attractive  for  that  reason.  It  is  also  risky. 
Through  risk  analysis,  the  consequence  of  failure  has  to 
be  examined  together  with  the  likelihood  of  failure.  If 
there  is  a  significant  probability  of  failure,  coupled  with 
a  potentially  severe  impact  on  the  program  plan,  par¬ 
allel  development  paths  may  be  appropriate,  no  matter  how 
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confident  the  engineer  is  that  he  can  handle  the  job. 

Parallel  development  often  can  be  undertaken  at  quite  low 
levels  of  effort  and  chopped  off  when  confidence  in  the 
success  of  the  main-path  effort  has  increased.  This  may 
appear  to  be  wasteful.  The  money  spent  in  this  way  is 
no  more  wasted,  however,  than  life  insurance  premiums  are 
wasted  because  one  does  not  succeed  in  dying  prematurely. 

Another  aspect  of  engineering  optimism  is  a  tendency 
to  assume  the  adequacy  of  an  engineering  solution  to  a 
problem  without  verifying  it  before  moving  on  to  the  next 
problem.  Having  sweated  through  the  solution,  it  may  seem 
to  be  pretty  straightforward.  The  tendency  is  to  assume 
that  because  it  ought  to  work,  it  is  going  to  work.  Criti¬ 
cal  aspects  of  performance  need  to  be  demonstrated,  and 
one  cannot  rely  on  the  development  engineer  to  check  him¬ 
self.  A  test  and  evaluation  program  has  to  be  imposed  on 
the  development  process — with  guidance  from  the  developer — 
but,  nonetheless,  imposed. 

The  problem  of  engineering  optimism  has  its  most 
upsetting  impact  when  it  results  in  changes  that  are  intro¬ 
duced  after  satisfactory  completion  of  component  or  subsystem 
development.  It  seems  so  simple  to  add  a  little  something 
here  or  improve  something  there.  Too  often  there  is  a 
totally  insufficient  analysis  of  the  possible  impact  of 
the  change  on  other  parts  of  the  system.  There  is  too 
little  attention  given  to  the  possibility  that  the  change 
may  invalidate  previous  test  results.  There  is  too  little 
concern  with  the  simple,  functional  solution  and  too  much 
attraction  in  the  more  complicated,  sophisticated  solution. 

It  is  bad  enough  if  optimism  impedes  program  development, 
but  it  is  much  worse  if  it  causes  things  that  work  satis¬ 
factorily  to  be  replaced  with  "better"  things  that  do  not 
work  as  well,  or  perhaps  do  not  work  at  all. 
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One  program  manager  in  industry  sums  up  his  approach 
to  controlling  optimism  as  pushing  the  worst  case  upon 
the  engineers: 


First,  you  ask  what  is  the  worst  thing  that 
could  happen.  Second,  you  ask  why  it  cannot 
happen  to  us.  Third,  you  ask  how  you  will  know 
it  has  happened — what  event  or  test  will  tell 
you.  Fourth,  you  ask  what  you  are  going  to  do 
if  it  happens.  These  questions  wring  out  most 
of  the  optimism  and  you  get  a  chance  to  look  at 
some  real  engineering  analysis  and  hard  facts . 


Customer  Relations 


Weapon  system  development  can  be  looked  upon  as  one 
step  in  a  long  series  of  user  disappointments.  In  the 
beginning  there  is  the  wish,  and  at  the  end  there  is  the 
sobering  reality  of  technology,  schedule,  and  budget. 
Between  the  beginning  and  the  end  are  disillusionments — 
popularly  called  trade-offs . 

The  user  is  the  program  manager's  customer.  The  user 
may  not  be  the  direct  source  of  the  system  requirements  and 
may  be  represented  by  a  requirements  activity.  In  that 
event,  the  program  manager  has  two  customers — and  a  more 
complex  problem  of  coordination.  The  whole  purpose  of 
weapon  system  development  is  to  satisfy  the  user's  need. 

The  program  manager  has  to  face  the  fact  that  he  may  have 
an  unhappy  customer  from  the  beginning.  Moreover,  the 
customer  will  become  even  more  unhappy  when  problems  which 
will  inevitably  arise  during  development  force  him  to 
retreat  still  further  from  the  system  capability  he  wants. 
Trade-offs  will  have  to  be  made  throughout  the  development 
process.  Since  the  user  is  the  customer,  he  must  partici¬ 
pate  in  the  trade-off  decisions.  If  the  program  manager, 
attempts  to  make  these  decisions  unilaterally  for  the  user 
he  is  courting  disaster. 
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A  direct  pipeline  to  the  user  activity  is  the  most 
effective  means  to  obtain  the  necessary  coordination  be¬ 
tween  the  program  office  and  the  customer.  Informal 
channels  are  no  less  important  than  formal  channels . 
Indeed,  from  the  program  manager's  view,  the  informal 
channels  are  more  important  because  they  flow  faster. 

The  importance  of  coordination  leads  many  experienced 
program  managers  to  urge  that  one  or  more  user  representa¬ 
tives  be  brought  into  the  program  office  right  from  the 
start.  Some  of  the  advantages  these  managers  see  can  be 
obtained  in  no  other  way: 

•  The  program  office  must  have  a  solid  feel 
for  the  system  requirements --why  they  are 
important,  how  they  were  established, 
whether  they  could  be  changed,  and  what 
the  impact  of  a  change  might  be  on  opera¬ 
tional  effectiveness .  The  best  way  to 
get  this  feel  is  for  your  engineers  to 
talk  with  the  people  who  know — not  from 
reading  papers . 

•  The  user  must  understand  the  problems 
being  encountered  during  development. 

If  he  isn't  where  the  action  is,  he  will 
not  understand  the  problems  and  cannot 
respond  to  them  intelligently. 

•  The  user  has  a  tendency  to  upgrade  the 
requirements,  especially  if  everything 
seems  to  be  going  well ,  trying  to  get 
back  some  of  what  he  lost  earlier  in 
trade-offs.  If  he  doesn't  know  what 
problems  still  remain  to  be  solved,  he 
can  have  too  rosy  a  view  of  only  a  small 
part  of  the  whole  program  picture. 

•  The  user  ordinarily  doesn't  have  a  good 
grasp  for  how  everything  ties  together  in 
the  program  plan.  He  wants  changes  made 
without  really  comprehending  the  probable 
impact  of  the  changes  on  technical  per¬ 
formance,  schedule,  or  cost  risks.  If 
the  user  develops  an  understanding  of  the 
complexity  of  the  undertaking,  he  is  going 
to  be  a  lot  easier  to  live  with.  Contact 
with  the  program  office  should  help  achieve 
this  goal. 
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•  Some  decisions  have  to  be  made  quickly.  A 
user  representative  will  know  how  to  get  an 
expedited  response  when  it  is  needed. 


The  need  to  check  requirements  directly  with  the  user 
is  illustrated  by  an  example: 


During  the  Korean  War  an  urgent  requirement 
was  received  for  an  antitank  warhead  capable  of 
penetrating  11  inches  of  armor.  Since  we  knew 
that  it  would  be  impossible  to  fire  perpendicular 
to  the  armor  under  all  circumstances,  we  took  a 
nominal  value  of  60  degrees  for  the  obliquity 
of  penetration  and  designed  a  shaped-charge  war¬ 
head  capable  of  punching  a  hole  through  18  inches 
of  armor.  This  weapon  was  to  be  delivered  to 
the  operating  services  in  great  haste.  Some  of 
us  became  curious  as  to  the  motive  power  employed 
by  Russian  tanks  that  would  enable  them  to  run 
around  over  rough  terrain  carrying  armor  11 
inches  thick.  Upon  investigation,  we  found  that 
the  actual  armor  of  the  tanks  had  a  thickness 
of  somewhere  between  three  and  four  inches,  and 
that  the  specification  given  us  had  resulted 
from  the  correction  for  obliquity  having  been 
made  twice  before,  while  the  specification  was 
coming  through  channels.  It  is  this  type  of 
well-meant  distortion  that  makes  it  essential 
for  the  designer  to  question  his  specifications 
and  to  go  back  to  primary  sources  in  order  to 
develop  a  real  understanding  of  his  problem 
and  the  basis  for  the  need,  if  he  is  to  create 
a  successful  product.* 


A  similar  need  for  direct  contact  arises  when  the 
first  operational  systems  are  delivered  to  the  user.  The 
program  manager  and  his  top  people  should  go  into  the 
field  and  work  with  the  users.  The  product  has  to  be 
sold.  One  program  manager  states: 


If  you  sit  back  and  wait  to  hear  how  it  goes, 
you  will  get  flak  you  won't  believe.  Everyone 


3: 

William  B.  McLean,  of  U.  S.  Naval  Ordnance  Test  Station, 
China  Lake,  California,  quoted  in  George  A.  Steiner  and 
William  G.  Ryan,  Industrial  Project  Management,  pp.  38-39. 
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up  and  down  the  line  will  get  so  upset  with  the 
shortcomings,  real  and  imagined,  that  you  won't 
even  have  a  chance  to  be  heard.  Work  with  the. 
user,  explain  why  things  are  the  way  they  are 
and  the  impact  of  changes  on  funds  and  schedule 
objectives,  solicit  his  cooperation,  and  show 
an  interest  in  getting  the  bad  points  fixed  as 
soon  as  possible.  The  user  is  happier,  and  you 
can  maintain  the  momentum  of  the  program. 


Logistics  Considerations 


Design  cannot  be  treated  separately  from  reliability 
and  maintainability  considerations  in  the  development  of  a 
weapon  system.  Good  results  are  what  we  want.  Bad  results 
can  be  obtained  in  either  of  two  ways:  by  a  design  which 
produces  a  system  that  is  not  effective  although  the  system 
is  reliable  and  easily  maintained,  or  by  a  design  which 
produces  a  system  that  is  never  working  when  it  is  needed. 
Which  condition  is  worse  makes  for  an  unproductive  debate. 

The  program  manager's  problem  is  that  design  and 
development  engineers  on  the  one  hand,  and  reliability  and 
maintainability  engineers  on  the  other,  are  each  specialists 
in  a  sense.  The  designer  tends  not  to  worry  enough  about 
logistics  considerations.  The  logistician  tends  not  to  be 
enough  concerned  about  the  operational  effectiveness  of 
the  system.  The  battle  is  usually  joined  on  the  proposi¬ 
tion  of  who  should  dominate  the  other.  The  designer  domin¬ 
ates  (as  ultimately  he  should)  ,>  but  schedule  and  cost 
objectives  usually  go  out  the  window  in  a  follow-on  program 
of  system  fix.  Resolution  of  the  issue  of  dominance  is 
not  the  problem — the  problem  is  balance  and  coordination 
to  achieve  something  more  in  concert  than  either  specialist 
would  achieve  separately . 

The  objective  of  weapon  system  development  is  to  get 
something  you  do  not  have  now.  Consequently,  at  least  in 
the  early  program  phases,  performance  objectives  and  cri¬ 
teria  must  have  a  dominant  voice.  But  this  does  not 
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necessarily  imply  that  design  decisions  should  be  made 
in  isolation  from  logistics  considerations.  The  trick 
is  to  find  a  way  of  fitting  the  two  activities  together 
on  an  informal,  day-to-day  basis — getting  across  the  idea 
that  good  design  includes  logistics  considerations  and 
that  the  logistician  can  help  the  designer  get  a  workable 
design.  The  key  seems  to  lie  in  putting  these  activities 
together  early  in  the  design  phases  and  encouraging  logis¬ 
tics  inputs  before  design  decisions  become  frozen.  If  the 
logistician  reviews  only  the  finished  design,  changes  he 
suggests  are  likely  to  have  unexpected  impact  on  the 
designer's  work.  The  designer  becomes  defensive  about 
his  design  because  he  doesn't  want  everything  upset.  The 
logistician  feels  ignored  because  the  designer  is,  in  fact, 
ignoring  him. 

The  need  for  this  pooling  of  design  and  logistics 
considerations  is  obvious .  How  can  it  be  achieved?  One 
effective  technique  is  in  the  use  of  life  cycle  cost 
analyses .  Although  all  costs  cannot  be  dealt  with  by 
these  analytical  techniques,  the  identification  of  what 
drives  the  major  cost  elements  over  the  life  of  a  system 
may  be  a  startling  revelation  to  the  designers.  Training, 
maintenance,  and  manpower  costs  are  likely  to  exceed  their 
wildest  imaginations.  Life  cycle  cost  studies  give  the 
designers  a  sense  of  appreciation  for  the  costs  of  their 
designs  and  how  those  costs  can  be  affected  by  changes  in 
their  designs.  Life  cycle  cost  cannot  be  developed  with¬ 
out  defining  and  comparing  maintenance  strategies.  Alter¬ 
native  strategies  and  their  costs  are  the  tools  the 
logistician  and  the  designer  need  to  obtain  logistics 
considerations  in  system  design. 

Experienced  program  managers  are  agreed  that  informal 
working  arrangements  and  close  physical  prdximity  are 
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essential  if  you  are  going  to  get  the  best  out  of  both 
specialties .  They  are  also  agreed  that  conflicts  between 
the  designer  and  the  logistician  are  no  different  from 
those  encountered  when  any  two  competing  specialties  bear 
on  a  common  subject.  It  is  one  more  example  of  what  many 
believe  to  be  the  most  serious  management  problem  faced 
by  the  program  manager — control  and  integration  of  specialty 
interests . 

Another  kind  of  problem  is  the  tendency  to  specify 
reliability  and  maintainability  goals  at  the  outset  of  the 
program  as  if  they  were  something  entirely  apart  from 
design.  Often  the  goals  are  unattainable.  Even  more 
likely,  demonstrating  their  achievement  would  be  possible 
only  at  a  prohibitive  cost.  This  sort  of  technical  never- 
never  land  weighs  heavily  on  the  designers  and  is  respon¬ 
sible  for  some  of  the  antagonism  the  designer  often  displays 
toward  the  logistician.  Whether  they  are  realistic  or  not, 
reliability  and  maintainability  requirements  generate  cost; 
unnecessary  requirements  generate  unnecessary  costs.  But, 
even  apart  from  the  effect  on  program  costs,  unattainable 
or  unmeasurable  requirements  drain  technical  effort  and 
divert  management  attention  away  from  the  main-stream  prob¬ 
lems.  This  kind  of  situation  is  fertile  ground  for  breeding 
what  one  manager  calls  "the  reliability  numerologist" — a 
fellow  who  is  engaged  in  spinning  an  endless  web  of  numbers, 
which  are  manipulated,  massaged,  extracted,  projected,  and 
predicted.  The  trouble  is  that  the  numerologist  doesn't  sit 
quietly  in  the  corner  wasting  a  small  amount  of  time  and 
money.  He  gets  everyone  into  the  act,  checking  this  and 
that,  and  he  wastes  an  unbelievable  amount  of  time  and  money. 

Technical  Futility 

Unattainable  technical  objectives— unattainable  in 
the  sense  of  obvious  incompatibilities  with  schedule  and 
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cost  constraints--sap  the  technical  morale.  They  also 
siphon  off  the  technical  effort  in  a  never-ending  exer¬ 
cise  of  paper  products  explaining  why  schedules  are  being 
missed  and  what  is  being  done  (supposedly)  to  attain  the 
desired  technical  objectives. 


There  is  a  school  of  thought  that  believes 
requirements  should  be  set  beyond  the  level  of 
normal  expectation,  in  order  to  push  the  state- 
of-the-art  and  insure  that  the  maximum  achievable 
level  of  performance  is  attained.  Results  achieved 
in  this  manner  are  almost  universally  at  high 
cost  and  not  justified  from  the  standpoint  of 
cost-effectiveness.  The  technique  of  setting 
unattainable  performance  goals  might  be  effec¬ 
tive  for  a  limited  research  and  development 
program  but  is  not  appropriate  where  total 
system  cost  is  already  large,  and  where  the 
cost  of  reaching  for  the  last  ounce  of  per¬ 
formance  is  economically  impracticable.* 


A  program  may  be  saddled  with  unattainable  technical 
objectives  at  the  start.  It  is  more  likely,  however,  that 
they  are  a  product  of  inflexible  response  to  problems 
uncovered  during  the  development.  Technical  objectives 
must  be  treated  as  goals  and  not  as  unchangeable  require¬ 
ments  .  They  must  be  reexamined  in  the  light  of  known 
facts  and  in  the  context  of  continuing  technical-schedule- 
cost  trade-offs.  A  practical,  flexible  response  to  problems 
is  an  essential  attribute  of  effective  management. 

In-House  Research  and  Development 

The  Services  have  established  a  number  of  research 
and  development  laboratories  covering  a  wide  range  of 
technical  and  scientific  fields.  Government  laboratory 
personnel  often  serve  as  technical  monitors  for  program 

National  Security  Industrial  Association,  op.  cit. , 


p.  32 . 
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offices  on  contracted  research  and  development  work. 

They  also  do  research,  design,  and  development  work  in 
their  own  right,  utilizing  valuable  capabilities  which  are 
sometimes  overlooked  in  systems  acquisition. 

For  a  program  manager,  these  laboratories  represent 
resources  which  can  be  exploited  in  the  development  of  a 
weapon . system.  Some  laboratories  have  outstanding  capabil¬ 
ities  in  their  scientific  fields.  They  may  be  able  to  do 
better  research  and  development  work  than  many  contractors . 
Several  program  managers  observed  that  in-house  research 
and  development  activities  could  often  respond  faster  than 
a  contractor  for  two  reasons:  first,  the  lead  time  for 
negotiation  and  award  of  a  contract  is  eliminated;  second, 
the  technical  team  is  in  being — it  does  not  have  to  be 
assembled . 

In-house  developments,  however,  carry  their  share 
of  management  problems.  The  primary  one  is  the  difficult 
process  of  transferring  technical  knowledge  from  a  govern¬ 
ment  laboratory  to  an  industrial  contractor.  Technical 
knowledge  involves  such  matters  as  shop  practices,  details 
of  layouts  and  processing,  and  other  information  which 
rarely,  if  ever,  get  reduced  to  writing.  Furthermore, 
there  is  a  considerable  difference  between  fabricating 
some  development  models  for  test  and  producing  a  quantity 
run  of  production  items .  In-house  developments  often 
suffer  from  the  attempt  to  go  from  development  to  production 
without  adequate  production  engineering.  Scientists  and 
engineers  with  a  special  talent  for  new  developments  usually 
are  not  very  much  concerned  about  the  problems  of  producing 
in  quantity  what  they  have  created.  Consequently,  when  a 
system  is  to  be  produced  by  a  contractor  who  did  not  partici¬ 
pate  in  the  development,  there  are  likely  to  be  more  prob¬ 
lems  than  would  be  expected  when  the  producer  is  also  the 
developer.  Program  managers  can  minimize  the  transition 
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problem  by  being  sure  that  potential  producers  are  brought 
into  the  program  early  enough  in  development  to  work  with 
the  laboratory  and  build  a  base  of  engineering  knowledge 
to  cope  with  technical  problems  in  production. 

In  addition  to  these  government-owned  laboratories , 
each  of  the  Services  has  one  or  more  sponsored,  not-for- 
profit  organizations — under  contract  to  and  working  for 
the  Department  of  Defense — to  assist  it  in  its  development 
programs.  These  organizations  are  known  as  Federal  Contract 
Research  Centers  (FCRCs) .  Some  of  them  are  system  engineer¬ 
ing  oriented,  and  provide  technical  management  and  coordina¬ 
tion  of  the  Services 1  contractors .  Others  are  laboratory 
oriented,  undertaking  research  and  development  of  new 
weapons.  Still  others  specialize  in  paper  studies  and 
analyses,  and  contribute  much  to-  the  cost-benefit  evaluations 
supporting  system  trade-off  decisions. 

The  System  View 

A  system  is  not  an  assemblage — although  many  systems 
have  evolved  in  a  way  exactly  fitting  the  artist's  defini¬ 
tion  of  "assemblage" — "an  artistic  composition  made  from 
scraps,  junk,  and  odds  and  ends." 

The  system  view  is  something  which  the  program  office 
provides  for  the  supporting  functional  elements.  It  is  also 
something  which  has  to  be  maintained  within  the  program 
office .  The  program  manager  must  have  a  technical  deputy 
he  trusts— someone  responsible  for  assuring  that  subsystem 
elements  are  more  than  merely  compatible.  They  must  be 
designed  as  part  of  a  harmonious  system  and  not  an  assem¬ 
blage.  The  need  for  a  technical  deputy  does  not  suggest 
that  the  program  manager  can  or  should  avoid  all  technical 
problems .  System  engineering  is  only  one  of  a  lot  of  things 
he  cannot  avoid,  but  he  cannot  be  the  system  engineer  and 
also  give  all  other  matters  the  attention  they  require. 
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The  system  view  is  also  needed  to  control  engineering 
optimism.  It  seems  to  be  a  law  of  nature  that  as  the 
development  progresses,  the  system  will  get  bigger  and 
never  smaller,  heavier  and  never  lighter — no  matter  how 
conscientious  the  planning  and  system  design.  System 
trade-offs  will  be  essential,  and  the  system  view  can  be 
obtained  only  if  you  stand  apart  from  subsys-tem  partisanship'. 


Measuring  Technical  Progress 


The  first  concern  of  most  managements  when 
considering  a  new  development  is  whether  the 
project  is  being  completed  within  the  original 
budget.  Its  second  interest  is  whether  the 
project  is  being  completed  in  scheduled  time, 
but  it  is  concerned  with  time  only  because 
"time  is  money".  This  principle  is  so  deeply 
ingrained  in  business  that  time  is  considered 
almost  synonymous  with  money.  Considering 
these  two  constraints,  where  does  technical 
performance  fit  into  this  syndrome?  Does  it 
hold  a  superior  position  (as  some  technical 
writers  have  stated)  or  a  lowly  one  (as  others 
have  said  with  some  bitterness)?  The  correct 
answer  is  neither.  In  fact,  cost  and  time 
cannot  be  measured  except  against  technical 
goals.  The  question  of  how  much  cost  or  how 
much  time  means  nothing  unless  it  is  accompanied 
by  "to  achieve  such  and  such  a  technical  per¬ 
formance"  .  * 


The  main  reason  for  focusing  on  budgets  and  time  is 
that  they  are  easy  to  measure.  Costs  incurred  and  the  time 
that  has  elapsed  are  easily  determined.  Actual  costs  and 
the  elapsed  time  can  easily  be  compared  with  an  earlier 
estimate  of  the  cost  and  time  it  would  take  to  do  the  whole 
job  to  obtain  a  measure  of  progress .  The  result  is  a 
measure  of  progress — of  how  fast  money  is  being  spent. 

What  is  not  known  is  anything  about  what  you  are  getting 

Peter  C.  Sandretto,  op.  cit. ,  pp.  133-134. 
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for  your  money  and  you  cannot  come  to  grips  with  the  cru¬ 
cial  issue:  How  much  is  it  likely  to  cost  and  how  long 
is  it  likely  to  take  to  get  done  what  you  need  to  have  done? 

Measuring  progress  in  a  useful  sense  involves  two 
things:  a  measure  of  achievement  and  a  measure  of  cost 

directly  correlated  with  the  achievement.  In  addition, 
there  must  be  confidence  that  what  has  been  achieved 
will  not  have  to  be  done  over  again.  This  implies  con¬ 
current  test  and  evaluation  tied  to  milestone  events  to 
ensure  that  the  costs  are  correlated,  with  real  achievements . 

Techniques  which  have  evolved  for  measuring  progress 
are  based  on  a  simple  proposition:  comparing  cost  and 
time  for  accomplishing  small,  discrete,  defined  pieces  of 
the  whole  job  with  earlier  estimates  for  accomplishing 
those  defined  pieces.  Each  successive  piece  of  the  job 
can  be  aggregated  with  those  preceding  to  give  a  measure 
of  change  in  the  direction  or  in  the  rate  of  the  variance 
from  plan.  These  pieces  are  called  "work  packages."  The 
definition  of  work  packages ,  tracking  the  cost  and  time 
to  complete  them,  and  comparing  actual  cost  with  earlier 
estimates,  are  the  core  elements  of  a  management  informa¬ 
tion  system  in  which  cost  and  time  can  be  measured  against 
goals.  When  combined  with  a  test  and  evaluation  program 
tailored  to  be  compatible  with  the  measures  of  cost  and 
time,  they  are  the  essential  elements  in  measuring  techni¬ 
cal  progress . 

Keep  It  Simple 

The  extreme  ingenuity  of  this  system  rather 

blinds  one  to  its  utter  uselessness . 

This  quote,  attributed  to  a  British  naval  officer,  has 
a  message:  Keep  everything  as  technically  simple  as  possible. 
Use  proven  components  and  subsystems,  and  proven  technology, 
whenever  possible.  Avoid  frills.  More  than  one  program 
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has  suffered  because  no  one  challenged  the  addition  of  a 
new,  sophisticated  component  for  some  additional  feature 
which  added  nothing  to  the  basic  purpose  of  the  weapon 
system. 


CHAPTER  FIVE 


SCHEDULE  PROBLEMS 


Optimism 

The  odds  are  that  the  program  manager  is  in  schedule 
trouble  even  before  he  has  a  chance  to  create  his  own 
problems.  He  is  in  trouble  at  the  outset  because  almost 
invariably  everything  has  taken  longer  than  anyone  supposed 
it  would.  It  is  a  safe  bet  that  much  of  the  program  lead 
time  has  melted  away  in  the  technical  and  administrative 
processes  of  defining  requirements  and  conceiving  the 
program.  By  the  time  the  program  is  shaped  up,  the  user 
is  already  in  a  froth.  In  spite  of  the  fact  that  every¬ 
thing  took  longer  in  the  past,  there  is  an  all  but  univer¬ 
sal  feeling  that  it  will  be  entirely  different  in  the 
future.  The  pressure  is  on.  It  may  even  be  possible 
to  make  up  some  of  the  lost  time — more  pressure  is  put 
on.  Optimism  becomes  the  order  of  the  day.  Program 
schedules  are  laid  out.  At  worst,  they  are  arbitrarily 
made  to  fit  an  inflexible  Initial  Operational  Capability 
date,  and  there  is  such  a  faint  chance  of  success  as  to 
amount  to  none  at  all.  At  best,  they  are  based  on  a 
view  of  paradise:  everything  works  right  the  first  time, 
nothing  goes  wrong,  nobody  makes  a  mistake. 

The  system  requiring  SECDEF  decisions  at  key  program 
points,  and  the  DSARC  program  reviews  which  are  a  part  of 
that  process,  will  temper  this  emphasis  on  accelerated 
schedules.  Nevertheless,  it  is  a  fact  that  time  is  the 
greatest  strain  for  program  managers. 

Time  is  likely  to  be  a  strain  even  in  the  best  of 
circumstances.  It  seems  to  be  a  rule  of  natural  law  that 
everything  takes  longer — even  the  things  that  seem  simple. 
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The  more  complex  the  development  undertaking,  the  less 
likely  we  are  to  understand  the  interrelationships  among 
its  many  parts  and  the  greater  is  the  likelihood  that 
unknowns  will  plague  the  program  schedule.  Weapon  system 
developments  are  complex  undertakings  no  matter  how  re¬ 
assuring  the  scheduler's  charts  may  appear. 

Inadequate  Planning 

Experienced  program  managers  point  to  three  basic 
weaknesses  in  schedule  planning:  inadequate  networking, 
inadequate  consideration  of  administrative  processing 
time,  and  inadequate  provision  for  contingencies. 

Planning  and  controlling  are  closely  related.  They 
are  so  closely  related  that  there  is  a  tendency  to  assume 
that  the  system  used  to  control  the  program  determines 
the  kind  and  detail  of  planning  which  should  be  done. 

This  is  wrong .  You  may  decide  that  you  do  not  need  a 
sophisticated,  computerized  control  system  (like  PERT) , 
but  you  still  need  to  lay  out  the  grubby  details  of  what 
you  are  going  to  have  to  do.  Networking  (which  is  usually 
associated  with  PERT)  is  a  way  of  pprtraying  what  has  to 
be  done.  Its  advantage  is  that  it  portrays  the  interrela¬ 
tionships  among  all  the  things  that  must  be  done.  It  shows 
the  dependency  of  future  activities  and  events  on  previous 
efforts.’  It  relates  activities  and  events  to  each  other 
over  time . 

Inadequate  networking  is  a  common  complaint  in  hind¬ 
sight.  If  they  had  it  to  do  over  again,  many  program 
managers  would  have  planning  done  in  more  detail,  not 
less.  There  is  agreement  that  more  detailed  networking 
would  have  resulted  in  fewer  important  things  being  over¬ 
looked.  One  program  manager  overlooked  the  fact  that  no 
allowance  had  been  made  for  procurement  lead  time — the 
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schedules  assumed  a  zero  delay  between  the  time  he  was 
ready  for  a  contractor  to  start  work  and  the  time  a 
contract  was  awarded.  Needless  to  say,  he  had  serious 
schedule  problems .  There  is  also  agreement  that  detailed 
networks  improve  risk  analysis  by  making  the  interrela¬ 
tionships  and  dependencies  of  events  more  visible.  Net¬ 
works  also  improve  effective  test  planning  for  the  same 
reasons . 


Another  advantage  of  detailed  planning  is  the  grasp 
of  the  program  which  the  program  manager  gets  by  working 
with  the  networks.  One  program  manager  puts  it  this  way: 


Getting  involved  in  the  networking  gives 
you  a  feel  for  the  whole  program.  You  get  an 
understanding  beyond  the  buzz  phrases .  You  can 
see  the  relationships  among  things  and,  most 
important,  you  can  talk  intelligently  about 
your  whole  program — why  you 'are  doing  things 
and  when  they  must  be  done.  You  get  a  feeling 
of  confidence  about  your  grasp  of  the  program 
that  is  communicated  to  others.  They,  in  turn, 
get  a  sense  of  confidence  in  your  ability  to 
manage  your  program.  When  people  up  the  chain 
don't  have  that  sense  of  confidence,  you  find 
that  they  take  over  the  program. 


Inadequate  consideration  of  the  time  it  takes  to 
process  paper  through  the  administrative  mill  is  another 
weakness .  It  is  a  problem  right  from  the  start  because 
it  takes  longer  to  build  up  the  program  office  than  was 
planned.  Schedules  start  to  slip  from  day  one,  and  the 
program  manager  is  hard  pressed  to  find  other  means  of 
accomplishing  what  he  intended  to  do  in  his  own  office. 

Problems  are  encountered  wherever  there  is  paper  to 
be  processed  or  approvals  to  be  sought.  Some  of  the  worst 
and  most  common  problems  of  optimistic  scheduling  are  in 
processing  procurement  actions.  It  takes  a  long  time  to 
pull  together  the  pieces  of  a  solicitation  package  and 
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to  go  through  the  many  steps  leading  to  a  contract  award. 

In  some  cases  it  takes  an  unbelievably  long  time .  This 
can  be  an  area  of  real  concern  because  dovetailed  schedules 
can  be  disrupted  and  it  can  become  impossible  to  meet  the 
planned  commitment  of  funds . 

It  appears  also  that  you  cannot  simply  assume  that 
those  responsible  for  processing  something  realiy  know 
how  long  it  will  take.  Functional  managers,  too,  seem 
to  underestimate  the  number  and  impact  of  unknown  problems. 
One  thing  you  can  do  is  to  talk  to  other  program  managers 
and  find  out  what  happened  to  them.  What  happened  to  their 
program  is  likely  to  be  closer  to  what  will  happen  to  your 
program  than  anything  else  you  hear.  Problems  have  a 
way  of  staying  much  the  same  for  a  long  time  and  affecting 
the  next  in  line  just  as  they  did  the  one  before. 

When  everything  has  been  carefully  scheduled  and 
thoughtful  estimates  applied  at  every  stage,  there  is 
still  one  problem:  It  will  not  work  out  that  way.  No 
matter  how  careful  or  how  thoughtful  the  plan  is,  something 
will  go  wrong.  There  must  be  slack  between  schedule  mile¬ 
stone  events  or  the  program  will  be  playing  catch-up  ball 
the  whole  way.  It  is  not  enough  only  to  have  slack.  It 

must  also  be  hidden  and  kept  secret  from  organizations 

> 

working  to  target  dates  specified  in  planning  documents. 
Once  slack  is  discovered,  it  will  evaporate  and  it  will 
have  disappeared  when  it  is  really  needed. 

Lack  of  Candor 

The  urge  to  present  a  favorable  image  to  others  leads 
many  to  discount  what  they  know  or  think  about  the  inevi¬ 
table  impact  of  a  problem.  It  leads  to  sanitizing  what 
they  tell  their  boss .  Judgment  is  replaced  by  a  childlike 
faith  that  somehow  the  problems  will  disappear  and  no  one 
will  know  they  were  ever  there. 
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When  the  program  manager  thinks  that  he  might  succumb 
to  this  urge ,  he  should  pause  to  consider  two  pitfalls . 
First,  it  works  only  for  a  little  while: 

The  idea  of  "buttering  up"  a  report  to 
management  so  that  they  will  hear  only  nice 
things  and  consequently  think  of  your  program 
in  nice  terms  falls  flat  when  the  first  major 
problem  that  you  cannot  cover  up  appears .  In¬ 
stead  of  being  aware  that  you  have  been  hard 
at  work  on  a  solution  for  weeks  and  something 
unforeseen  occurred,  top  management  will  sud¬ 
denly  be  confronted  with  a  major  problem.  They 
can  then  become  quite  unhappy  with  the  program 
progress.  They  had  not  been  informed  properly.* 

Second,  the  program  manager's  own  staff  will  do  unto 
him  what  they  see  him  do  unto  others .  Things  really  do 
go  out  of  control  then.  The  boss  is  not  likely  to  think 
that  the  program  manager  is  not  aware  of  what  is  going 
on  in  his  program — the  boss  will  know  it. 

The  need  for  candor  in  reporting  and  assessing  actual 
or  potential  problems  is  illustrated  by  viewing  a  program 
in  the  perspective  of  related  programs.  If  delays  can  be 
reasonably  anticipated  in  a  program,  there  are  options 
available  to  decision-makers.  One  option  is  to  pour  more 
money  into  that  program  to  recover  schedule .  Another 
option  may  be  to  extend  the  use  of  an  existing  system 
and  accept  schedule  delays  in  developing  the  new  system. 

If  problems  are  hidden  long  enough,  the  options  may  dis¬ 
appear.  It  may  be  impossible  to  extend  the  use  of  an 
existing  system  because  necessary  production  lead  time  has 
been  lost.  There  may  not  be  time  to  replenish  an  inventory 
of  spare  parts  deliberately  reduced  in  anticipation  of 
phasing  out  the  old  weapon  system.  Decision-makers  are 
understandably  inclined  to  be  perturbed  when  viable  alter- 

£  ■ 

Melvin  Silverman,  The  Technical  Program  Manager's 
Guide  to  Survival,  John  Wiley  &  Sons,  Inc.,  1967,  p.  62. 
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native  decisions  are  reduced  to  one--panic! — because  the 
facts  were  deliberately  obscured  earlier,  when  other 
alternative  courses  of  action  were  still  feasible. 


Inadequate  Control  of  Events 

Schedule  problems  are  not  always  thrust  upon  the 
program  office.  Some  can  develop  inside  the  program  office. 

The  natural  tendency  of  scientists  and  engineers, 
whether  in  industry  or  in  government,  is  to  seek  technical 
perfection.  The  natural  consequence  of  this  tendency  is 
that  they  regard  schedules  as  of  secondary  importance. 
Someone  has  to  emphasize  the  fact  that  schedules  are 
important- -perhaps  even  more  important  than  the  last 
measure  of  small  improvement  in  technical  performance. 

In  the  words  of  one  program  manager: 

Design  engineers  will  fiddle  and  tinker 
forever.  If  you  let  them  alone,  you  are 
guaranteed  to  have  schedule  slippages  and 
cost  problems .  Nothing  will  come  out  of 
the  end  of  the  pipe  unless  you  push  it  out. 

One  technique  that  works  for  me  when  I 
see  them  at  the  fiddling  stage — making  things 
a  little  better  and  not  worrying  about  the 
schedule — is  to  shove  an  absolute  deadline 
on  them  and  tell  them  that  we  will  just  have 
to  go  with  what  is  available  then.  As  a 
matter  of  fact,  it  is  often  surprising  how 
much  they  squeeze  out  of  the  last  few  weeks. 

They  just  don't  like  the  idea  of  your  going 
with  less  than  the  best. 


Management  Information  Systems 

Management  systems  are  frequently  mistaken  for  manage¬ 
ment.  This  mistake  is  most  evident  when  people  speak  of 
management  control  systems — which  really  do  not  control 
anything.  They  should  speak  of  management  information 
systems,  since  these  systems  only  provide  data  which 
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someone  may  use  to  focus  on  items  going  out  of  control. 
Management  information  systems  can  also  provide  so  much 
data  that  control  is  impossible  because  no  one  can  thresh 
the  mountain  of  material  reported.  Modern  computer 
technology  has  solved  the  problem  of  storing  and  retrieving 
data.  It  is  one  of  the  few  items  the  program  manager  has 
in  long  supply. 

Reliance  on  unanalyzed  data  is  equivalent  to  assuming 
that  systems  and  not  people — control.  This  assumption  is 
a  mistake.  What  the  program  manager  needs  is  some  way  to 
analyze  the  data,  to  get  rid  of  the  chaff,  and  to  have 
information  presented  in  a  form  he  can  understand.  Most 
important,  he  needs  it  in  a  form  he  can  use;  that  is,  in 
a  form  which  will  provide  at  least  four  things: 

(1)  A  ranking  of  problem  areas  by  criticality. 

(2)  An  indication  of  potential  trouble  spots. 

(3)  Anticipated  schedule  slippage  and  cost 
overruns  or  underruns . 

(4)  A  means  of  determining  where  management  can 
withdraw  resources  to  assist  more  critical 
phases . * 

Management  information  systems  can  portray  a  false 
picture  based  on  erroneous  information  as  easily  and 
prettily  as  they  can  display  an  accurate  picture  based  on 
valid  information.  A  realization  of  this  fact  is  basic 
to  a  healthy  skepticism  in  the  MIC.  This  is  not  a  new 
or  novel  idea: 

It  may  be  difficult  to  obtain  accurate 

and  timely  reports  of  progress .  It  is  not 

uncommon  among  PERT  users  to  receive  feeder 

£ 

John  Stanley  Baumgartner,  Project  Management,  Richard 
D.  Irwin,  Inc.,  1963,  p.  49.  Mr.  Baumgartner  has  an  excel¬ 
lent,  and  brief,  discussion  of  a  technique  to  do  these  things 
by  what  he  calls  "The  Status  Index"  on  pp.  48-60  and  175-177. 
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reports  indicating  progress  in  accordance  with 
plan;  and  then  suddenly,  in  a  two-week  period, 
two  or  more  weeks '  negative  slack  is  reported 
which  means  literally  that  during  the  two-week 
period  no  work  or  negative  work  was  accom¬ 
plished.  A  look  at  the  expense  report  indicates 
normal  expenditures;  the  quickly  arrived  at 
conclusion  is  that  previous  reports  of  progress 
were  not  correct.  Frequently,  in-house  and  sub¬ 
contract  working  groups  are  reluctant  to  admit 
difficulties  until  the  difficulties  would  have 
been  discovered  anyway.  By  the  time  the  true 
schedule  position  is  admitted  the  PM  may  sud¬ 
denly  find  himself  in  serious  cost  and  progress 
difficulty. * 


What  is  true  of  the  program  office's  system  is  also 
true  of  its  contractors.  The  industry  project  manager  may 
have  an  inadequate  system  to  support  him,  and  he  may  use 
inadequate  techniques  to  ferret  out  the  truth.  If  this 
is  so,  the  information  furnished  to  the  program  office 
will  be  wrong.  More  important,  the  contractor  is  likely 
to  have  schedule  and  cost  problems  resulting  from  inade¬ 
quate  control.  In  almost  every  case,  the  contractor's 
problems  burn  the  program  as  well  as  the  contractor . 
Consequently,  it  is  simply  good  business  practice  to 
check  out  the  contractor's  methods  before  relying  on 
them.  Government  people  often  assume  there  is  in  in¬ 
dustry  a  degree  of  sophistication  and  skill  in  management 
that  simply  does  not  exist  in  a  specific  company.  The 
existence  of  the  skill  must  be  verified,  not  assumed. 
"C/SCSC"  (Cost/Schedule  Control  Systems  Criteria)  is 
essentially  a  specification  intended  to  assure  the  com¬ 
pleteness,  accuracy,  and  integrity  of  different  systems 
used  by  contractors  to  track  cost  and  progress.  The 
validation  of  an  individual  contractor's  system  by  the 
government  is  a  process  of  checking  out  his  methods . 

* 

Ibid.,  p.  35. 
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While  a  validation  gives  assurance  that  the  contractor 
has  acceptable  methods,  it  does  not  establish  any  specific 
requirements  for  reporting  cost  or  progress  to  the  program 
manager.  The  program  manager  must  still  establish  and 
define  his  requirements  in  terms  of  what  he  needs  to  manage 
contracted  work. 

One  program  manager  observed  that  it  was  amazing  how 
little  information  he  really  needed  and  used  to  help  him 
manage  his  program.  His  needs  were  basically  satisfied 
by  the  relatively  simple  reporting  requirements  described 
by  Mr.  Baumgartner.  At  the  same  time,  he  also  observed 
how  easy  it  was  for  the  program  office  to  be  carried  away 
with  information  display — what  he  called  "an  artist's  view 
of  managing  programs . "  A  management  information  center 
is  a  wonderful  piece  of  public  relations--especially 
captivating  for  those  who  have  never  managed  programs . 

One  thing  is  certain,  however:  every  program  manager 
regrets  any  idea  he  may  have  had  that  he  could  really 
manage  his  program  in  the  comfort  of  the  big  swrvel  chair 
in  the  MIC.. 

In  looking  back  at  my  experiences  in 
development,  including  watching  a  number  of 
Navy  developments  over  the  past  few  years,  it 
seems  quite  clear  that  in  most  cases  where  a 
system  gets  into  trouble  a  competent  manager 
knows  all  about  the  problem  and  is  well  on  his 
way  to  fixing  it  before  his  management  systems 
ever  indicate  that  it  is  about  to  happen.  This 
happens  if  for  no  other  reason  than  because  the 
competent  manager  is  watching  what  is  going  on 
in  great  detail  and  perceives  it  long  before 
it  flows  through  the  paper  system.  That  is 
to  say  personal  contact  is  faster  than  form 

and  the  U.  S.  mails.  A  project  manager 
who  spends  his  time  in  his  Management  Informa¬ 
tion  Center  instead  of  roving  through  the 
places  where  the  work  is  being  done  is  always 
headed  for  catastrophe.  The  MIC  can  be  an 
assist  to  the  people  who  are  involved  in  the 
project  toward  learning  of  after-the-fact 
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problems,  but  that  is  roughly  all  that  it  can 
do,  and  its  value  even  for  this  purpose  is 
frequently  questionable.* 

Bureaucratic  Apathy 

Allied  with  the  problem  of  administrative  lead  time 
is  the  danger  of  bureaucratic  apathy  affecting  the  program 
office.  Its  symptoms  are  long  review  and  approval  chains, 
slow  responses  to  correspondence,  a  reluctance  to  seek 
or  approve  waivers  from  standard  procedures,  and  a  faith 
that  the  way  something  has  always  been  done  in  the  past 
must  be  the  right  way  to  do  it.  It  is  a  sure  sign  that 
the  steam  is  going  out  of  the  organization. 

An  occasional  look  at  some  routing  sheets  and  at 
referenced  dates  in  correspondence  is  about  all  that  is 
needed  to  uncover  the  problem.  An  intolerance  for  the 
symptoms — especially  for  expressions  of  faith  in  the 
excellence  of  current  practices — will  go  far  to  preserve 
the  free  spirit  that  is  one  of  the  important  assets  of 
program  management. 

Funding  Changes 

One  of  the  rules  of  the  program  management  game  is  that 
the  only  sure  way  to  have  money  is  to  get  rid  of  it.  Until 
funds  are  obligated  by  contract,  they  may  be  snatched  away 
for  any  number  of  laudable  reasons--none  of  which  benefits 
the  program  which  loses  its  funds.  One  program  manager  de¬ 
scribes  the  situation  this  way: 

If  you  want  to  protect  your  program,  you 
have  to  fight  for  it.  You  especially  have  to 
fight  for  funds .  One  or  another  program  is 


Robert  A.  Frosch,  "The  Emerging  Shape  of  Policies  for 
the  Acquisition  of  Major  Systems,"  Naval  Engineers  Journal, 
August  1969,  pp.  20-21. 
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always  in  trouble  and  someone  is  sure  to  be 
looking  for  money .  They  want  to  swap  their 
problems  for  your  money.  It  may  be  a  provin¬ 
cial  attitude,  but  I  think  a  program  manager 
is  expected  to  push  for  his  program.  That 
means  two  things:  first,  grab  for  your  money; 
second ,  get  it  into  contracts  and  work  orders 
as  soon  as  possible.  You  have  to  plan  and 
schedule  your  contract  actions  early  in  the 
fiscal  year.  You  have  to  make  sure  you  are 
moving  your  money  out  as  planned. 


Changes  in  funding  also  have  an  impact  on  the  psychology 
of  schedules .  Funding  changes  always  result  in  schedule 
changes.  Schedule  changes  may  be  necessary,  but  they  hurt: 

A  schedule  is  only  as  firm  as  the  esteem 
given  it  by  people  working  on  the  project. 

When  schedules  change  frequently ,  whatever 
the  reason,  or  where  there  are  doubts  and 
second  guesses  about  the  "actual"  schedule, 
the  validity  of  the  schedule  as  an  element 
of  control  is  weakened.* 


Notwithstanding  his  best  efforts,  it  is  a  rare  and 
fortunate  program  manager  who  does  not  have  to  absorb 
reductions  in  funds  or  reprogramming  of  funds  to  later 
fiscal  years.  Advance  planning  for  these  contingencies 
is  recommended  strongly.  Higher  authority  is  likely  to 
want  to  know  the  impact  of  funding  changes  on  ridiculously 
short  notice  and  some  advance  planning  reduces  the  turmoil 
of  responding.  In  addition,  an  inadequately  supported 
response  is  detrimental  to  maintaining  one's  image  as  a 
manager  who  is  on  top  of  his  program. 

Government-Furnished  Material 

Seldom,  if  ever,  is  there  a  program  in  which  a  single 
contractor  furnishes  the  complete  weapon  system.  Usually 
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there  are  several  contractors,  whose  products  flow  to  the 
system  integration  contractor,  along  with  other  items 
furnished  by  the  government.  In  many  cases,  major  sub¬ 
systems  of  the  complete  weapon  system  are  assemblies  of 
components,  some  furnished  by  the  subsystem  contractor 
and  some  received  by  the  subsystem  contractor  to  be  joined 
with  what  he  is  furnishing.  The  crucial  distinction  between 
government— furnished  and  contractor— furnished  material  is 
that  the  government  assumes  a  responsibility  for  the  proper 
functioning  and  on-time  delivery  of  government— furnished 
items .  The  contractor  assumes  this  responsibility  for 
items  he  furnishes ,  including  items  obtained  from  his 
subcontractors . 

Government- furnished  equipments  (GFE)  are  physical 
components  used  in  the  system  or  as  aids  in  the  development 
of  the  system.  Government- furnished  information  (GFI)  is 
descriptive  of  the  form  and  fit  of  the  GFE  to  follow, 
specifying  requirements  which  must  be  provided  and  func¬ 
tions  performed — such  as  dimensions,  weight,  power  inputs, 
outputs,  and  so  forth.  GFE  and  GFI  are  notorious  for  the 
schedule  and  cost  problems  they  generate.  If  they  are  not 
furnished  to  the  contractor  when  promised,  the  government 
is  responsible  for  any  consequent  delay  and  for  any  added 
costs  attributable  to  that  delay.  As  a  result,  problems 
associated  with  GFE  and  GFI  are  a  frequent  source  of  claims 
by  contractors  against  the  government. 

From  the  program  manager's  viewpoint,  there  are  two 
kinds  of  GFE/GFI .  In  one  case,  there  are  items  needed  by 
his  system  prime  contractor  from  another  contractor,  and 
the  program  manager  has  direct  control  over  both  contractors. 
In  another  case,  there  are  items  which  are  needed  by  one  of 
his  contractors  from  a  source  not  under  the  program  manager's 
direct  control.  A  different  organizational  element  may  be 
responsible  or,  perhaps,  a  different  Service. 
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There  are  problems  of  coordination  to  ensure  adequate 
performance  with  both  kinds ,  but  they  are  more  severe  with 
items  (and  especially  with  development  items)  not  under 
the  direct  control  of  the  program  office.  Distance  and 
differing  responsibilities  lead  to  a  diminished  sense  of 
participation  in  the  program.  When  coupled  with  an  all 
too  human  tendency  to  shuffle  off  our  problems  on  others, 
distance  and  indifference  have  potentially  explosive 
implications . 

GFI  which  must  be  fed  into  the  program  on  schedule 
may  be  furnished  on  time  solely  to  avoid  unpleasantries. 
What  may  not  be  furnished  is  the  knowledge  that  the  GFE 
development  program  is  slipping  and  that  what  was  supposed 
to  be  definite,  firm,  and  certain  is  very  uncertain  and 
likely  to  be  changed.  The  program  office  assumes  that  the 
information  furnished  is  reliable.  Design  decisions  are 
made  based  on  that  information,  and  they,  in  turn,  become 
the  basis  for  succeeding  design  decisions.  Changes  in 
the  GFI,  which  might  well  have  been  anticipated  if  there 
had  been  complete  candor  earlier,  can  cause  a  lot  of  wasted 
technical  work.  It  might  have  been  possible  to  work  around 
the  problem,  but  the  opportunity  to  do  so  is  lost  if  no 
one  advises  that  there  is  a  problem. 

Prevention,  not  cure,  is  the  only  feasible  remedy. 

Avoid  system  designs  which  force  the  program  to  rely  on 
developmental  items  of  GFE.  That  is  sometimes  impossible. 

In  that  case,  the  program  office  must  monitor  critical  items 
of  GFE  and  GFI  furnished  from  outside  sources  as  closely  as 
it  monitors  the  hardware  for  which  it  is  directly  responsi¬ 
ble.  This  means  getting  out  in  the  field,  getting  close 
to  the  work,  and  checking  facts.  Finally,  the  GFE  managers 
have  to  be  made  a  part  of  the  program  team  through  coordin¬ 
ation  meetings,  where  they  can  get  a  sense  of  their  part 
in  the  enterprise  and  some  feeling  of  responsibility  for 
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its  success .  Face-to-face  contact  with  the  people  who  will 
be  forced  to  live  with  the  problems  they  generate  is  strong 
preventive  medicine . 


CHAPTER  SIX 


COST  PROBLEMS 


Sources  of  Cost  Growth 


The  experiences  of  more  than  30  major  programs  over 
an  extended  period  of  time  give  some  indication  of  the 
problems  of  cost  growth  most  likely  to  beset  new  programs. 
These  program  histories  show  that  the  factors  contributing 
to  cost  growth  and  their  approximate  impact  were: 

•  Changes  in  Cost  Estimates — refinements  of  the 
base  program  estimate — accounted  for  40  percent 
of  the  total  cost  growth. 

•  Engineering  Changes — alterations  in  physical 
or  functional  characteristics — 20  percent. 

•  Schedule  Changes — changes  in  delivery  schedules 
or  program  milestones — 1 5  percent. 

•  Economic  Changes — escalation  adjustments  in 
contracts  and  other  changes  in  the  purchasing 
power  of  the  dollar — 10  percent. 

•  Support  Changes — changes  in  spare  parts, 
training,  testing,  and  other  support  require¬ 
ments — 7  percent. 


A  variety  of  other  items  made  up  the  balance  of  some 
8  percent  of  the  total  cost  growth  in  these  programs.* 

Price  Optimism 


In  much  the  same  way  as  he  inherits  going— in  schedule 
problems,  the  program  manager  inherits  going-in  cost 
problems.  The  odds  are  overwhelming  that  the  initial, 
"first-pass"  program  cost  estimate  was  too  low.  Price 
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optimism  is  a  term  used  to  describe  how  this  situation 
arises ,  and  changes  in  cost  estimates  (the  largest  item 
by  far  in  cost  growth)  are  the  result.  Price  optimism 
is  mostly  a  result  of  the  usual  optimism  we  have  in 
situations  of  great  uncertainty- -we  do  not  grasp  the 
import  or  magnitude  of  actual  or  potential  problems. 

It  is  also  partly  a  result  of  a  self-serving  bias  that 
aggravates  the  situation. 


There  is  a  natural  tendency  on  the  part 
of  DoD  and  industry  to  foster  unrealism  in 
initial  estimates  of  program  cost,  timing  for 
hardware  availability,  and  capability  to  meet 
performance  criteria.  First-pass  cost  estimates 
of  new  weapon  systems  or  a  new  defense  capability 
tend  to  be  inaccurate  because  of  lack  of  defini¬ 
tion  and  objectivity,  coupled  with  inadequate 
estimating  skills.  Insufficent  attention  is 
given  to  what  is  realistic  in  the  sense  that 
it  is  practical  of  attainment  in  the  immediate 
or  foreseeable  future — based  upon  experienced 
and  knowledgeable  judgment. 


Parochial  interests  on  the  part  of  both 
DoD  and  industry  tend  to  produce  unduly  opti¬ 
mistic  estimates.  Competition  for  military 
roles  and  funds  to  promote  favored  programs , 
and  the  desire  to  maintain  or  increase  business 
growth  and  backlog,  have  resulted  in  a  pattern 
of  marketeering  and  overselling.  From  Congress 
down  the  acquisition  chain,  realism  too  often 
has  not  been  recognized  as  an  essential  element 
of  evaluation  and  decision  making.* 


The  cost  estimating  problem  is  the  basic  problem. 
Optimism  slants  the  result  because  we  really  do  not  know 
the  right  answer.  If  we  knew  what  the  right  answer 
should  be,  it  would  be  possible  to  root  out  the  facts 
to  confront  the  fiction.  It  is  another  story  when  fact 
and  fiction  are  indistinguishable.  Since,  as  Dr.  Frosch 
says,  we  purchase  objectives  in  development,  and  not 
ob jects--since  what  we  purchase  does  not  have  real 


"k 

NSIA,  op .  cit . ,  pp.  12,  14. 


86 


characteristics  and  there  is  no  defined  real  price--then 
program  cost  estimates  must  necessarily  be  very  uncertain 
and  valid  only  in  very  gross  terms.  Optimism  will  not  be 
bounded  effectively. 

Two  operating  concepts  are  implicit  in  the  uncer¬ 
tainty  that  seems  to  be  inherent  in  program  cost  estimating. 
First,  truly  effective  cost  control  can  be  achieved  only 
by  constraining  initial  program  requirements.  Second, 
established  requirements  must  be  repeatedly  reexamined 
in  the  light  of  unfolding  knowledge  of  their  cost  implica¬ 
tions  . 

Constraining  the  initial  requirements  is  one  way  to 
be  sure  that  program  costs  are  not  greater  than  they  must 
be.  While  we  may  not  know  what  something  will  cost  in 
absolute  terms,  we  do  know  that  additional  requirements 
will  add  tc  its  cost.  Unnecessary  performance  requirements 
which  are  beyond  a  state-of-the-art,  disruptive  changes  in 
requirements,  concurrency  of  development  and  production  when 
designs  are  likely  to  change,  all  add  to  the  total  cost — 
and  result  in  more  cost  than  need  have  been  incurred. 

As  development  progresses,  the  probable  cost  of 
achieving  one  or  another  stated  performance  objective 
becomes  more  evident.  At  the  same  time,  the  cost  impli¬ 
cations  of  backing  off  from  the  established  requirements 
can  be  assessed  more  accurately.  If  the  cost  of  achieving 
the  stated  objectives  is  going  to  be  greater  than  antici¬ 
pated,  it  is  necessary  to  ask  whether  lesser  requirements 
are  now  acceptable  or  whether  the  added  costs  are  inescapable. 
What  is  essential  is  that  there  be  an  opportunity  to  make 
these  trade-off  decisions  before  everyone  is  committed  to 
the  higher  cost  alternative.  The  program  information  sys¬ 
tem  must  alert  management  to  the  fact  that  a  trade-off 
decision  must  be  made  in  a  context  where  no  decision  is 
equivalent  to  opting  for  inevitable  cost  increases. 


87 


Engineering  Changes 

Changes  and  the  need  to  control  changes  were  discussed 
in  Chapter  Two.  The  focus  there  was  on  formal  changes: 
changes  issued  by  the  contracting  officer  which  directly 
and  explicitly  address  their  effect  on  schedule  and  cost 
objectives.  Some  changes  are  doubtless  going  to  be  essen¬ 
tial  to  embrace  new  technology  or  to  respond  to  a  changed 
threat.  Change  control  seeks  to  distinguish  the  essential 
from  the  unessential.  It  seeks  to  avoid  the  disruptive, 
and  perhaps  catastrophic,  effect  of  innocent-looking,  nice- 
to-have  changes .  Change  control  implies  a  searching  examin¬ 
ation  of  the  effect  a  change  may  have  on  schedule  and  cost 
objectives  before  a  decision  is  made.  Change  control  is 
rooted  in  a  conviction  that  there  is  no  such  thing  as  a 
technical  necessity  entirely  independent  of  the  cost  and 
time  to  achieve  it. 

Formal  changes  are  issued  by  the  contracting  officer 
only  after  prescribed  reviews  and  coordination  with  the 
program  office.  They  are  not  necessarily  easy  to  control, 
but  at  least  they  are  easy  to  identify. 

There  are  other  changes  not  so  easy  to  identify. 
Collectively,  they  are  called  constructive  changes.  They 
amount  to  the  same  thing  as  formal  changes  except  that 
no  one  has  directly  and  explicitly  addressed  their  impact 
on  schedule  and  cost.  The  government's  responsibility  for 
both  types  of  changes  is  essentially  the  same.  The  effect 
of  a  constructive  change  on  schedule  and  cost  is  not 
addressed  before  the  change:  the  government  simply  pays 
later  when  its  liability  for  claims  by  contractors  is 
the  subject  then  to  be  addressed. 

A  list  of  these  informal,  constructive  changes  would 
include : 
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•  Defective  specifications  which  cause  the  contractor 
to  do  extra  work . 

•  Requiring  or  authorizing  work  that  is  not  specified 
under  the  explicit  terms  of  -the  contract. 

•  Directing  the  contractor  to  do  work  in  a  way  not 
required  by  the  terms  of  the  contract. 

•  Adding  inspection  requirements. 

•  Requiring  adherence  to  schedules  notwithstanding 
delays  caused  by  the  government — such  as  late 
delivery  of  GFE . 

Constructive  changes  can  easily  take  place  in  the 
informal  process  of  program  management — in  meetings  and 
by  correspondence — especially  when  the  program  manager 
his  deputy  is  involved.  Such  changes  are  prone  to 
arise  in  situations  where  a  contract  is  viewed  (as  some 
technical  people  view  it)  as  a  fussy  necessity  and  some¬ 
thing  to  be  largely  ignored. 

There  are  three  things  a  program  manager  can  do  to 
control  these  changes.  First,  he  can  make  his  position 
on  the  importance  of  the  contract  terms  clear  to  his  own 
staff  and  the  contractor.  If  the  program  manager  intends 
that  there  be  no  informal  changes ,  he  had  better  make  it 
clear  to  everyone.  Second,  he  can  practice  what  he  preaches. 
Third,  he  can  encourage  (even  demand)  active  participation 
by  his  legal  and  contract  advisers  in  the  day-to-day 
operations  and  activities  of  the  program  office. 

Schedule  Changes 

Program  schedule  changes  cost  money.  It  costs  if  the 
schedule  is  stretched-out ,  and  it  costs  if  the  schedule  is 
accelerated. 

Stretch-outs  add  to  total  program  costs  because  fixed 
operating  costs  of  contractors  and  laboratories  (deprecia¬ 
tion  of  buildings  and  equipment,  management  salaries,  and 
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other  overhead)  will  be  allocated  over  a  longer  period  of 
time.  Those  costs  will  be  allocated  at  a  higher  rate,  also, 
except  in  the  unlikely  event  that  additional  work  is  obtained 
from  another  source  to  offset  the  lower  level  of  effort  in 
the  program.  Additional  costs  are  also  incurred  in  rework¬ 
ing  production  engineering  and  other  scheduling  efforts. 
Finally,  added  costs  may  be  generated  by  maintaining  an 
engineering  or  other  capability  which  cannot  be  effectively 
assigned  elsewhere. 

Acceleration  adds  to  total  program  costs  by  requiring 
recruiting  and  training  of  new  personnel,  overtime  and 
shift  premium  pay,  acquisition  of  additional  facilities 
and  equipment,  and  duplication  of  scheduling  efforts. 

Schedule  changes  are  often  the  result  of  changes  in 
funding  levels.  Much  of  the  time,  there  is  little  the 
program  manager  can  do  to  protect  his  program  against  the 
effect  of  major  budget  reallocations.  The  best  defense-- 
possibly  the  only  defense — is  to  make  sure  that  higher 
authority  knows  in  advance  and  in  as  much  detail  as  possi¬ 
ble  what  the  consequences  of  budget  changes  will  be. 

Budgeting  for  Target  Costs 

There  is  a  form  of  optimism  which  can  be  traced 
to  budgetary  myopia  in  the  program  office.  It  is  myopic 
because  it  does  not  take  into  account  future  events,  and 
it  attributes  to  contracts  qualities  they  do  not  have. 

The  most  obvious  manifestation  of  this  optimism  is 
treating  cost  reimbursement  contracts  as  if  they  were  for 
fixed  dollar  amounts.  Budget  people  sometimes  lose  sight 
of  the  fact  that  the  very  reason  for  using  that  type  of 
contract  should  effectively  dispel  any  such  idea.  Program 
management  people  sometimes  lose  sight  of  the  same  thing. 

The  basic  reason  a  cost-reimbursement  contract  is  used  is 
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that  the  actual  cost  of  doing  the  work  is  highly  uncertain. 
The  estimated  cost  is  not  a  price — it  is  an  objective.  At 
the  very  least,  one  must  anticipate  the  possibility  (many 
would  say  probability)  that  the  cost  of  the  work  will  exceed 
the  objective. 

A  similar  form  of  the  problem  is  often  encountered 
in  budgeting  for  fixed-price  incentive  contracts .  A  target 
price  is  negotiated.  Recognizing  that  it  is  likely  that  it 
will  cost  more  than  the  target  price  to  do  the  work,  provi¬ 
sion  is  made  in  the  contract  allowing  for  a  specified  upward 
adjustment  of  the  price.  What  often  happens  is  that  every¬ 
one  forgets  about  the  spread  between  the  target  and  ceiling 
prices.  The  target  price  is  the  one  everyone  talks  about, 
budgets  for,  and  counts  on — -until  the  bill  is  received. 

There  is  then  a  realization  that  'something  important  was 
overlooked,  and  a  scramble  ensues  to  find  the  funds. 

A  somewhat  related  problem  is  the  tendency  to  ignore 
budgetary  planning  for  changes  and  contingencies .  The 
source  of  this  problem  is  the  same  tendency  to  view  con¬ 
tracts  as  setting  unchanging,  fixed  dollar  limits  for  the 
work  needed.  A  little  checking  around  and  inquiring  into 
the  experiences  of  other  programs  will  soon  disclose  that 
contract  changes  must  be  anticipated.  Program  managers 
can  get  some  feeling  for  the  possible  magnitude  of  this 
problem  by  looking  at  what  has  happened  in  a  few  programs 
of  comparable  size  and  complexity. 

Unnecessary  Documentation 


Unnecessary  documentation  comes  in  two  varieties:  not 
really  needed  at  all;  and  not  needed  when  it  is  required  to 
be  furnished  and  likely  to  change  before  it  is  really  needed. 
In  each  case,  the  result  is  useless  effort — and  at  avoidable 
expense.  There  is  a  large  hidden  cost,  also.  There  is  at 
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least  one  person  (and  usually  more  than  one)  who  will  study, 
critique,  evaluate,  question,  and  file  every  document  which 
is  prepared.  Indeed,  the  cost  of  preparation  is  only  a 
small  part  of  the  total  cost.  Follow-on  costs  after  distri¬ 
bution  must  be  enormous. 


Industry  sees  the  problem  clearly: 


On  many  programs  involving  complex  hardware, 
technical  data  such  as  drawings,  manuals,  fore¬ 
casts,  and  various  plans  and  procedures  are  re¬ 
quired  prematurely.  These  premature  requirements 
result  in  excessive  contractor  efforts  to  meet 
initial  commitments--often  with  inferior  data — 
and  extensive  additional  efforts  to  correct  or 
redo  the  data.  Government  personnel  must  also 
review,  comment  on,  and  re-review  such  data. 

It  is  unrealistic  to  establish  requirements 
for  early  submittals  of  many  items  of  technical 
data  without  considering  the  status  and  availa¬ 
bility  of  a  firm  technical  definition  of  the 
equipment  to  which  the  requirement  pertains.* * 


The  problem  looks  much  the  same  when  viewed  from 
within  the  defense  establishment: 


I  have  seen  overruns  in  expenditure  and 
unnecessary  effort  generated  by  the  fact  that 
the  linear  sequencing  of  milestones  had  forced 
development  of  a  complete  maintenance  and  re¬ 
liability  plan  for  what  was  no  longer  the  de¬ 
sign,  and  had  not  been  the  design  for  three 
months .  The  machinery  forced  everyone  to  grind 
on  and  on  because,  after  all,  the  maintenance 
and  reliability  milestones  could  not  be  missed 
without  disaster  and  fear  of  cancellation  of  the 
project,  even  though  the  plan  being  worked  out 
had  nothing  whatever  to  do  with  the  hardware 
being  designed.** 


Different  Appropriations 

A  different  kind  of  cost  problem  arises  because  the 

program  office  deals  with  different  kinds  of  funds. 

— 
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Robert  A.  Frosch,  Naval  Engineers  Journal,  p.  22. 
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Appropriations  come  in  various  kinds ,  with  varying  periods 
of  authorized  use,  and  program  money  management  requires 
deft  skills.  One  program  manager  described  the  problem  in 
these  terms : 


We  all  know  that  appropriations  are  not 
interchangeable.  Finds  for  RDT&E  cannot  be 
reprogrammed  for  O&M  or  Production.  The  same 
conditions  generally  hold  for  all  combinations . 
This  means  that  it  is  important  to  program  the 
right  types  of  money  to  support  all  aspects  of 
a  project--the  aggregate  amount  of  funds  is 
of  quite  limited  value  unless  the  pieces  fit 
the  categories  of  work  to  be  performed.  There 
are  some  very  narrow  overlapping  areas  where 
some  interchangeability  may  be  accomplished, 
but  they  are  quite  limited.  Recognition  and 
negotiation  of  these  areas  are  best  left  to 
the  experts — those  in  the  Budget  Office.  Never 
underestimate  the  value  of  the  man  heading 
that  office. 


Similar  problems  arise  through  failure  to  budget 
adequate  funds  for  travel  and  overtime  work,  although 
the  very  nature  of  program  management  activities  will 
require  much  of  both.  Program  managers  often  find  that 
they  do  not  have  control  of  the  budgeting  or  allocation 
of  these  funds.  They  must  get  in  line  with  many  other 
managers  and  compete  for  the  funds  they  need. 


A  Matter  of  Emphasis 

Cost  control  is  largely  a  matter  of  continuing 
attention  and  emphasis .  The  problem  is  that  most  of 
the  excitement  is  associated  with  technical  performance 
and  schedule  objectives.  In  defense  weapon  system 
acquisition,  the  ultimate  user — the  fighting  force-- 
does  not  budget  or  pay  for  the  development.  The  money 
flows  through  another  channel  and,  naturally,  the  user 
is  not  especially  conscious  of  or  concerned  with  cost. 
What  the  fighting  force  wants  is  the  best  performance 
and  the  earliest  delivery.  Since  it  is  not  directly 
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concerned  with  the  funding  problem,  it  can  emphatically 
voice  its  desires  without  worrying  much  about  their  cost 
implications.  Moreover,  as  noted  earlier,  industry  sources 
have  a  similar  bias  toward  technical  and  schedule  objectives. 
If  cost  objectives  are  going  to  be  emphasized  in  any  prac¬ 
tical  way,  it  will  be  only  because  the  program  manager 
assumes  that  responsibility.  It  may  appear  to  others  that 
he  views  cost  in  an  unbalanced  way--seeming  to  emphasize 
cost  more  strongly  than  technical  and  schedule  objectives. 
That  is  probably  the  way  it  must  appear  if  overall  program 
balance  is  going  to  be  achieved. 


CHAPTER  SEVEN 


THE  EFFECTIVE  MANAGER 


Peter  F.  Drucker  says  that  the  job  of  the  executive  is 
to  be  effective,  and  effectiveness  is  getting  the  right  things 
done-.  Ineffectiveness  is  not  synonymous  with  laziness.  On 
the  contrary,  ineffectiveness  is  often  characterized  by  a 
frenzy  of  busywork,  a  childlike  fascination  with,  and  con¬ 
centration  on,  what  is  interesting,  what  is  familiar,  what 
one  is  good  at  doing — and  a  corresponding  avoidance  of  what 
needs  to  be  done.  The  hardest  things  a  manager  has  to  do 
is  to  wean  himself  away  from  what  he  likes  to  do  and  become 
adjusted  to  a  diet  of  different  activities. 


Mr.  Drucker  assures  his  readers  that  effectiveness  can 
be  learned.  He  sees  it  being  learned  through  five  practices 
or  habits  of  the  mind  which  must  be  acquired: 

(1)  Effective  executives  know  where  their  time  goes. 
They  work  systematically  at  managing  the  little 
of  their  time  that  can  be  brought  under  their 
control . 

(2)  Effective  executives  focus  on  outward  contri¬ 
bution.  They  gear  their  efforts  to  results 
rather  than  to  work.  They  start  out  with  the 
question,  "What  results  are  expected  of  me?" 
rather  than  with  the  work  to  be  done,  let  alone 
with  its  techniques  and  tools . 

(3)  Effective  executives  build  on  strengths — their 
own  strengths,  the  strengths  of  their  superiors, 
colleagues,  and  subordinates;  and  on  the  strengths 
in  the  situation,  that  is,  on  what  they  can  do. 
They  do  not  build  on  weakness.  They  do  not  start 
out  with  the  things  they  cannot  do. 

(4)  Effective  executives  concentrate  on  the  few  major 
areas  where  superior  performance  will  produce 
outstanding  results.  They  force  themselves  to 
set  priorities  and  stay  with  their  priority  de¬ 
cisions.  They  know  that  they  have  no  choice  but 
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to  do  first  things  first — and  second  things 
not  at  all.  The  alternative  is  to  get 
nothing  done . 

(5)  Effective  executives,  finally,  make  effective 
decisions.  They  know  that  this  is,  above  all, 
a  matter  of  system — of  the  right  steps  in  the 
right  sequence.  They  know  that  an  effective 
decision  is  always  a  judgment  based  on  "dis¬ 
senting  opinions"  rather  than  on  "consensus 
of  the  facts . "  And  they  know  that  to  make 
many  decisions  fast  means  to  make  the  wrong 
decisions.  What  is  needed  are  few,  but 
fundamental,  decisions.  What  is  needed  is 
the  right  strategy  rather  than  razzle-dazzle 
tactics . * 

The  first  two  items — managing  the  little  time  he  can 
control  and  focusing  on  his  particular  contribution — have 
special  relevance  for  military  program  managers.  The  items 
are  related:  The  program  manager  has  little  time  he  can 
control  because  briefings,  reporting,  and  budget  presenta¬ 
tions  take  so  much  of  his  time;  but  these  are  also  the 
occasions  for  a  special  contribution  only  he  can  make. 

That  contribution  is  the  creation  and  maintenance  of  the 
program's  image  to  the  world  outside  the  program  office. 

One  program  manager  puts  it  this  way: 


The  program  manager's  main  job  is  to  make 
the  program  look  good.  I  don't  mean  to  fake  it. 

I  mean  to  be  on  top  of  the  program,  to  anticipate 
what  the  boss  expects,  what  the  budget  people 
expect,  what  OSD  expects,  and  even  what  Congress 
expects.  The  image  of  an  energetic,  capable 
program  is  a  great  asset  in  recruiting  the  people 
you  want  in  the  program  office,  and  in  obtaining 
the  right  kind  of  support  from  functional  organ¬ 
izations.  The  morale  and  success  of  the  program 
office  staff  are  largely  a  reflection  of  that 
image.  A  good  image  results  in  cooperation  and 
a  bad  image  results  in  struggling  all  the  time  to 
get  what  you  need.  The  program  manager  has  to  be 
the  outside  man — the  salesman,  if  you  wish  to  call 
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him  that — and  his  deputy  should  run  the  in-house 
work . 

Nothing  dampens  spirit  faster  than  a  system  where  every¬ 
thing  stops  at  the  program  manager's  desk  waiting  for  his 
return  from  somewhere.  If  he  is  not  careful,  the  boss  can 
become  the  chief  clerk  and  proofreader  in  the  office — the 
one  who  checks  everything  to  make  sure  it  is  right.  Weigh¬ 
ing  the  risks  on  both  sides ,  there  is  a  consensus  among 
program  managers  that  there  is  only  one  way  to  go.  That 
way  is  to  select  the  best  people  you  can  get,  give  them  a 
free  rein,  and  rely  on  being  able  to  fix  their  mistakes 
without  too  much  damage  being  done. 

There  is  another  consensus  that  weekly  staff  meetings 
are  both  a  must  and  an  adequate  backstop  to  catch  the  really 
significant  mistakes.  If  weekly  meetings  are  not  an  ade¬ 
quate  backstop,  the  problem  is  not  organization  but  ineffec¬ 
tive  subordinates.  The  solution  is  not  centralization  of 
decision-making  but  replacement  of  personnel.  This  is  just 
another  aspect  of  being  effective  as  a  manager,  which  is  the 
job  of  a  military  program  manager. 
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